Thursday, September 18, 2014

Chrome Invalidates Certificates using SHA-1 in November 2014

Certificates are used to secure digital communication. The most common security measure is SSL/TLS which is used to protect communication with web sites and other services. The certificates used to secure communication have an algorithm that is used to create has values. SHA-1 was a commonly used hash algorithm.

In November of 2013, Microsoft indicated that Windows would not accept certificates using SHA-1 as valid starting in 2017. Most certificates expire after 1-3 years providing ample time to update existing certificates during normal renewal processes.

I just received a notification that Google Chrome will start marking web sites using certificates with SHA-1 as invalid starting in November 2014 if the expiry date of that certificate is after 2015. That is a much faster time frame.

A review of our clients has revealed that only one certificate is using SHA-1 at this time. All of the others are using SHA-256 (one of the larger set of SHA-2 algorithms). For this one client, we need to rekey the certificate to use the new algorithm.

Specific instructions for rekeying vary depending on your SSL provider.

Some potential issues with SHA-2:
  • If you have legacy servers such as Windows Server 2003, you need to update them to support SHA-2 by installing a hotfix (http://support.microsoft.com/kb/968730). This is required for Exchange 2003 servers if you have them or older web servers.
  • If you are using GoDaddy digital signing certificates, the Java security store does not automatically trust the SHA-2 based certificates yet. Apparently, this is in the works and will be complete within the next few months. So, in the short term you may want to keep SHA-1 for that purpose. The Chrome change in November 2014 won't affect Java signing.

References:

Monday, September 15, 2014

Windows 9 Has a Start Menu

Some screenshots and videos are showing up for Windows 9 Technical Preview. I'm not sure what else is in there, but the one I care about is the Start menu. It's back!

Right from the time Windows 8 came out, it bothered me that they tried to use a tablet interface on desktop computers. According to articles, Windows 9 will change the interface depending on the type of device. So, tablets can retain the Start screen (which makes sense) and PCs can have the start menu.

If this all turns out to be true for the release product I think I can finally get customers moving on the new OS instead of sticking with Windows 7.

A YouTube video of the Windows 9 Start menu is below:


Please note that the product name of Windows 9 is not yet confirmed.

Wednesday, September 3, 2014

Saturday, August 16, 2014

Network Error When Adding DAG Member in DR Site

I was adding a new DAG member in a disaster recovery (DR) site and got an error about networking. The error was as follows:
A server-side administrative operation has failed. 'GetDagNetworkConfig' failed on the server. Error: The NetworkManager has not yet been initialized. Check the event logs to determine the cause. [Server: NewMember.domain.com] It was running the command 'Get-DatabaseAvailabilityGroupNetwork | Sort-Objects -Property Name'.
This error is due to Active Directory replication latency to the DR site. The server in the DR site does not have the Active Directory changes in the configuration partition yet. However, if you look at Failover Cluster Manager, the new server is up in the DAG cluster.

You have two options:
  1. Wait for replication to complete. This typically takes 15 minutes between sites.
  2. Trigger replication to speed it up. After I triggered replication to the remote site and then triggered replication back the error was gone right away and I could move on with adding my database copies for the DR site.

 

Preseeding Exchange 2010 Databases in DR Site

One of our clients uses a remote location as a disaster recovery (DR) site for Exchange. The purpose of the DR site is less about functionality (although, it is usable), it's more about the offsite backup functionality this provides.

Last week, the Exchange server in the DR site failed and after rebuilding it, we needed to get it going again. The link speed to the remote location is only about 5 Mbps on which they can move about 50 GB of data per day. Given that they have 250GB of mail data, seeding over the network would have resulting in about 5 days of seeding if there were no network interruptions.

The process for preseeding is clearly described in the Microsoft documentation and works as advertised:
  1. Clean up an incorrect data for the database such as database copies that no longer exist if you are in a recovery situation.
  2. Disable circular logging on the database. You are going to take a copy of the database and the log files generated between when you take a copy and when you start it on the new server are copied to bring it up to a current state.
  3. Dismount the database and copy the files (database, logfiles, and index) to portable media. You need to dismount the database to ensure that the copy you have is consistent. Alternatively, if you can't afford the outage to copy the database, you can backup your database and restore to portable media. That backup will have a consistent copy of the database. You could also briefly dismount the database, take a volume shadow copy, mount the database, and use the volume shadow copy as your source.
  4. Remount the database. When you remount the database users can begin using their mailboxes again.
  5. On the new server copy the files from portable media. Remember that the file path for a database copy needs to be exactly the same on all servers. So, put it in the exact same path.
  6. On the new server add the mailbox database copy by using the Exchange Management Shell. You need to use EMS to use the -SeedingPostponed parameter that indicates that the database is already there and not to copy over top of it. You do not need to run a command to indicate you are ready, the database starts up immediately.
  7. Wait for log files to replicate and replay. Now the database mounts locally and all log files since the copy are replicated to the new server and replay on the copied database.
  8. Finally, if you were using circular logging you can reenable it on the database.
To add the database copy in step 6 use this command:
Add-MailboxDatabaseCopy -Identity DbName -MailboxServer MbxServerName -SeedingPostponed
The Microsoft documentation is here:

Friday, August 15, 2014

Blue Screen Win32k.sys 0x50

Yesterday we had one client lose 5 machines to a stop error when they rebooted. This is caused by a bad Microsoft update. Specifically, KB2982791 which updates fonts. If you search around there were previous issues cause by font updates and the font cache not being cleared properly.

Yesterday, we fixed up a couple of the machines by doing a system restore and delaying all updates because we were not sure of the cause. I'm now seeing postings that indicating that removing the font cache file may allow the system to boot. Delete this file:
  • C:\Windows\System32\fntcache.dat
For your reference, this Microsoft forum with a post by Iaurens provides step by step instructions on how to recover by booting from a Windows 7 Install DVD.
Such a pity, we had just started doing auto approvals of updates for some clients again. I guess we'll move back to the manual approval mode so that we can delay updates like this that are likely to get pulled.

I should note that I don't think this is widespread as we've only had one client with the issue. Strangely it was their Engineering users with the issue. So, I'm guessing it's some type of software interaction causing the issue.

If you are using WSUS, I strongly suggest you decline KB2982791.

Update: Further reading suggests that KB2970228 is also bad and should be declined at this time.

Update, Aug 29/14: More drama. Apparently the replacement update for this also has some issues. Although less severe. Read someone else's rant here:

Tuesday, August 5, 2014

Remove OEMDRV Drive from Dell Server

I recently installed a Dell Server by using the Lifecycle Controller. This system uses a wizard to help with the installation of the operating system. In this case, I was installing Windows Server 2008 R2 to replace an existing Exchange 2010 server.

As part of the installation, an OEMDRV USB drive is created by the Lifecycle Controller that contains the drivers used during OS installation. OS installation went well, but I ran into an issue afterwards. The OEMDRV drive was using E:, which I needed for my Exchange data.

When you go into computer management, OEMDRV shows as a removable drive. However, you cannot change the drive letter or eject OEMDRV. By default the Lifecycle controller removes this drive after 18 hours, but I didn't want to wait that long.

To force OEMDRV to be removed earlier, restart the server and press F10 to enter the Lifecycle Controller configuration. Then exit the Lifecycle Controller and reboot again. You don't need to make any changes in the configuration. Just entering and exiting triggers the removal.