The May 2019 Microsoft patch releases included an update for a very high-risk vulnerability (CVE-2019-0708, aka BlueKeep) that affects Windows XP, Windows 7, Server 2003, Server 2008, and Server 2008 R2.
This vulnerability allows an unauthenticated attacker (or malware) to remotely execute code on the vulnerable system. It is considered as VERY high risk, particularly for systems with Remote Desktop Protocol (RDP, port 3389) directly exposed to the Internet. However if a system inside the network is compromised it could easily spread to other PC's and servers because RDP is enabled by default.
CoNetrix strongly recommends all customers ensure the May updates are installed as soon as possible.
Microsoft has not only released updates for Windows 7, Server 2008 & R2, but also has issued updates for Windows XP and Server 2003 which are not officially supported.
All CoNetrix Technology customers with managed services agreements and all cloud hosted Aspire systems, were updated shortly after this vulnerability was announced.
This vulnerability can be mitigated by enabling Network Level Authentication (NLA) - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732713(v=ws.11). Additionally CoNetrix recommends disabling RDP access over the Internet to internal systems.
The Microsoft Assessment Planning (MAP) Toolkit is a useful utility that can be used to gather hardware and software information for workstations and servers. After installing the toolkit, you can provide domain credentials which it uses to poll each device in Active Directory and gather information about the devices it finds. This data can be viewed through various Excel reports and can help to shorten the time it takes to fill out an audit questionnaire.
The toolkit can be downloaded from: https://www.microsoft.com/en-us/download/details.aspx?&id=7826
We recently encountered a strange issue with a customer running Outlook 2010 in an Exchange 2007 environment. Some users (not all) would randomly get certificate warning pop-ups in Outlook. The certificate warnings indicated the Fully Qualified Domain Name (FQDN) "autodiscover.customerdomain.com" wasn’t on the certificate. The certificate warning was legitimate; that FQDN was not on the certificate because this customer didn't have a UCC certificate.
However, all the autodiscover SCP records had been changed via Powershell to point the autodiscover URL to "webmail.customerdomain.com" which WAS on the certificate. All the PCs were joined to the Active Directory domain so the SCP lookup should have had precedence over any other autodiscover method. Doing an autodiscover check via the Outlook system tray icon indicated the certificate warning pop-up and all the values returned by the test were all correct.
The question was why were these PC's even contacting "autodiscover.customerdomain.com"? After much troubleshooting, we found that even though the domain SCP records were correct, some Outlook clients were also doing DNS lookups for "autodiscover.customerdomain.com" in parallel with the SCP lookup. Checking DNS there was an "autodiscover.customerdomain.com" A record and pointed to the IP address of the Exchange server; however, since that FQDN wasn’t a subject alternate name on the certificate, it would have legitimately generated the certificate warning.
The resolution was to simply remove the "autodiscover.customerdomain.com" A record from DNS and we added SRV records for good measure. It doesn’t seem like having that A record in DNS would have mattered since the autodiscover priority shouldn’t have ever used it, but from now on we will use DNS SRV records and SCP exclusively for Exchange autodiscover.
Starting in Windows 7 and Windows Server 2008 R2, Microsoft introduced sub-category configuration audit policies. This provides administrators with added granularity when deciding which event logs are necessary to be logged. More on Advanced Audit Policies can be found here: http://technet.microsoft.com/en-us/library/dd772712(WS.10).aspx [more]
The following command will pull the configuration for all of the new advanced security audit policies:
audipol /get /category:*
Several of our customers have been confused recently regarding the number of Microsoft licenses they own. The issue is confused by Microsoft’s process itself. When a customer purchases licensing they are issued an Open Business Authorization certificate which states the number of licenses purchased.
The client is also issued a set of keys to install the purchased licenses. The license number and the number of times the customer can use the key are very confusing. In fact the key can be used roughly 5 times per 1 license. As an example, if a customer purchases 10 Windows Server licenses, the associated key may state a quantity of 50. This actually means you can activate the key 50 times on the same 10 licenses.
If you seem to have extra licenses that magically appeared, make sure you are looking at your certificate and not the number associated with the keys.
You assume, that both Microsoft and Lenovo will create a restore point before applying updates to your computer. I did… and it cost me dearly! I had to rebuild my machine from scratch! Restore points require disk storage, and there is a screen (see below) where the amount of the disk to be used for restore points is specified. In my case the amount was set to “0” (zero), and then when the Lenovo updater tries to create a restore point, it failed. There was no warning that it failed! [more]
I’ve been upgrading our internal Office Communication system to the new Lync 2010 environment. Everything I had been reading showed the two servers can run side-by-side, albeit with different pools created. Running side-by-side allows for easy testing and migration rather than switching everyone over and hoping it works. Unfortunately, what I didn’t realize was the two servers use some of the same database names. While Microsoft has documented this, you have to dig a little through the documentation to find it.
I discovered this travesty soon after I hit the magic “go” button. This button (also known as “Publish topology”) started the deployment of the Central Management Store into my SQL instance. This process involves taking existing databases and placing them into restricted mode. Then the installer attempts to drop the database and recreate it. Since these were OCS R2 databases, however, the Lync installer had problems recreating over the existing table layout. The whole process choked, leaving the databases in a funky, inconsistent, restricted state and communicator non-functional. I was able to connect as ‘sa’ and remove the restriction, but the databases were pretty much a lost cause. Restoring from the previous night’s backup allowed everyone get back online.
Moral of the story: Here’s yet another Microsoft product that does not warn you before dropping databases. Be wary when installing applications that automatically set up databases as part of the installation procedure.