Amazon Banner

Friday, May 5, 2017

Data Sharing Service crashes on Windows Server 2016 - Event ID 7023

While troubleshooting an issue recently on a Windows Server 2016 system, I noticed errors on the System event log about the Data Sharing Service crashing.

The Data Sharing Service service terminated with the following error:  %%3239247874
The Data Sharing Service service terminated with the following error: %%3239247874

Searching online for more information about this service and why it might be failing, I came across a lot of people describing similar problems, but the only explanation and solution I found came from this December blog post by Microsoft Japan.    Google translate did a great job making the post understandable to me, but since the information doesn't seem to have been widely publicized I thought I'd share it here to help get the word out.

The Data Sharing Service fails due to a resource conflict with another service included in Server 2016, the User Access Logging Service.  Either one of these services alone will run without issue, but if one is already running and you try to start the other, it will fail.

According to an update to the blog post, Microsoft plans to resolve the issue in a future update to Server 2016, but in the mean time there is a simple workaround that will allow the Data Sharing Service and User Access Logging Service to live in harmony.  The internal resource conflict occurs because the two services are running in a shared process.  By configuring the services to each run in their own process, the conflict is avoided and both services can be running at the same time.  Run these two commands to change the configuration:
Sc config ualsvc type=own
Sc config dssvc type=own

Successful result of SC Commands

After changing the service configuration, you should now be able to start the Data Sharing Service successfully.  

Wednesday, August 17, 2016

Windows 10 Credential Guard breaks WiFi

Recently, I ran into an issue with computers running windows 10 that would not connect to our WPA2-Enterprise encrypted wifi network.  When it failed to connect, there was no indication of why, only the message "Can't connect to this network."  The computers were able to connect to unencrypted networks and networks using a Pre-shared key for WPA encryption without issue.

Checking the event logs on the RADIUS server to see why the comptuer failed to connect, there was no log entry for a connection attempt from the affected system.  The WLAN-Auto-Config log on the client listed a couple of errors, including Event ID 11006 and 12013, but other than showing that the failure reason was "Explicit EAP failure received", they didn't give much to go on:

Log Name:      Microsoft-Windows-WLAN-AutoConfig/Operational
Source:        Microsoft-Windows-WLAN-AutoConfig
Date:          8/15/2016 1:11:20 PM
Event ID:      11006
Task Category: MsmSecurity
Level:         Error
Keywords:      (1024),(512)
User:          SYSTEM
Wireless security failed.
Network Adapter: Intel(R) Dual Band Wireless-AC 7265
Interface GUID: {32a54564-27eb-479a-82f3-10a9b736f9d8}
Local MAC Address: AA:BB:CC:DD:EE:FF
Network SSID: CHC1
BSS Type: Infrastructure
Peer MAC Address: 00:11:22:33:44:55
Reason: Explicit Eap failure received
Error: 0x80070285
Log Name:      Microsoft-Windows-WLAN-AutoConfig/Operational
Source:        Microsoft-Windows-WLAN-AutoConfig
Date:          8/15/2016 1:11:20 PM
Event ID:      12013
Task Category: OneXAuthentication
Level:         Error
Keywords:      (1024),(512)
User:          SYSTEM
Wireless 802.1x authentication failed.
Network Adapter: Intel(R) Dual Band Wireless-AC 7265
Interface GUID: {32a54564-27eb-479a-82f3-10a9b736f9d8}
Local MAC Address: AA:BB:CC:DD:EE:FF
Network SSID: CHC1
BSS Type: Infrastructure
Peer MAC Address: 00:11:22:33:44:55
Identity: host/
Reason: Explicit Eap failure received
Error: 0x80070285
EAP Reason: 0x285
EAP Root cause String: There was an internal authentication error.
EAP Error: 0x285 
After spending significant time toubleshooting the issue, I found that the issue was caused by the new "Credential Guard" feature in windows 10.  In the technet article documenting this new feature, there is a single line which explains why this was happening:
Credential Guard also does not allow unconstrained Kerberos delegation, NTLMv1, MS-CHAPv2, Digest, CredSSP, and Kerberos DES encryption.
As it turns out, our radius server and the GPO which pushed our wireless settings out to clients were configured to use MS PEAP for authentication.  At first glance, that doesn't seem to conflict with the statement above, but the P in PEAP stands for protected.  It basically creates an encrypted tunnel first, over which standard EAP authentication takes place.  The EAP communication travelling through that encrypted connection can be configured to use either "Secured Password (EAP-MSCHAP v2)" or "Smart Card or other Certificate".  You can guess which mine was using.

For a Credential Guard enabled computer to authenticate to a WPA2-Enterprise wireless network, the network must use certificate based authentication.  In my case, we already had the PKI in place, so it was a simple matter of configuring the RADIUS server to accept certificate based authentication and changing the Wireless Settings in our GPO to use a certificate for authentication instead of the Secured Password option.  After making these changes and connecting these clients to ethernet to get a group policy update, they were able to successfully authenticate with and connect to the WPA2-Enterprise encrypted network. If you don't already have a Public Key Infrastructure (PKI) set up, this will require installing configuring the Certificate Authority role on a Windows server, and issuing certificates to users and/or computers.  (Ideally, configuring computers to auto enroll with the CA for computer certificates.)

When I was searching online for what could possibly cause my issue, searching for the error message and event details I had turned up nothing useful.  Any posts I found from others with similar errors turned out to be unrelated.  In the end, I did find a single page by Nigel Kemp documenting his experience with this issue, but only after I had already identified the likely culprit and searched specifically for "Credential Guard breaks Wifi".  Still, I was thankful to have the confirmation that I was on the right track.  I hope that by including the specific errors and events in this blog post, it will help others find the solution to this problem a little easier.

Friday, April 29, 2016

Configuring Bitlocker and TPM on Server 2012R2 Core

I've just finished configuring Bitlocker on a new server running Server Core 2012R2 with a TPM key protector.  I had to piece together bits from a few sources online to accomplish this, so I will bring together in this one post all of the steps I ended up using.

Here's a high level overview of the steps required:

  1. Check TPM status
  2. Enable & activate TPM if needed
  3. Take ownership of TPM
  4. Create Bitlocker recovery password
  5. Backup recovery password to Active Directory
  6. Enable Bitlocker using the TPM as the key protector

In order to do this, the server must have a TPM module installed.  Believe it or not, this is still not standard hardware for many servers.  For HP servers, a TPM add-on is available for about $50 as p/n 488069-B21.  If you do have to install a TPM, go into the BIOS and enable the TPM under the security settings, to save yourself some steps later.

Now comes the tricky part.  Powershell version 4 added some handy new cmdlets for managing the TPM.  Unfortunately, for some reason those cmdlets are not included in Server Core installs, so we have to resort to using WMI.  The Scripting Guy has a great blog post that gets into all of the details on this, written by guest blogger Stephane van Gulick, which my process was based on.

First, use WMI to get the Win32_TPM class, which contains all of the methods required for managing the TPM.  By assigning it to a variable $TPM, we can use the variable to call the methods we need.

$Tpm = Get-CIMClass -Namespace ROOT\CIMV2\Security\MicrosoftTpm -Class Win32_Tpm

Next, run the following commands to check the current status of the TPM.


Each of those commands will return a boolean true or false.  If the TPM isn't enabled, enable it using:


Once the TPM is enabled and activated, it's time to take ownership.  If the TPM is already owned, it will need to be cleared first.  Then, prepare a TPM owner password to be used, and take ownership.

$password = 'P@ssword'
$tpmpassword = $tpm.ConvertToOwnerAuth($password).OwnerAuth

Now the Trusted Platform Module is enabled, active, owned, and ready to store the Bitlocker key protector.  But before we can start encrypting the drive, the Bitlocker feature must be installed using 'install-windowsfeature'

Install-WindowsFeature Bitlocker

At this point, I tried to enable bitlocker using a TPM protector, but because our group policy settings require that a bitlocker recovery password be backed up to Active Directory, the command failed.

According to the documentation for Enable-Bitlocker, the there are several parameters which can be used to specify what type of key protector should be used.  While some of these parameters include multiple protectors, The TPMProtector and RecoveryPasswordProtector options are mutually exclusive, and cannot be combined.  Lucky for me, the documentation also includes this handy tip to point me in the right direction:
It is common practice to add a recovery password to an operating system volume by using the Add-BitLockerKeyProtector cmdlet, and then save the recovery password by using the Backup-BitLockerKeyProtector cmdlet, and then enable BitLocker for the drive. This procedure ensures that you have a recovery option.
Use the Add-BitlockerKeyProtector cmdlet to create the recovery password.  Then find the protector ID and use it to back up the recovery password to Active Directory using Backup-BitlockerKeyProtector.  (It may not be necessary to run Backup-BitlockerKeyProtector if group policy requires the password be backed up when created, but it won't hurt anything to back it up again just to be safe.)

add-bitlockerkeyprotector -mountpoint c: -recoverypasswordprotector
$BLV = Get-BitLockerVolume -MountPoint "C:"
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

I ran Enable-Bitlocker again, but once again hit a snag:

Because my group policy also requires that OS drives encrypted with Bitlocker use a TPM protector, it appears that a TPM protector was assigned automatically when I added the Recovery Password protector.  Since the drive was already set up with a TPM protector, the enable command failed when it tried to add another. The Enable-Bitlocker command requires the use of one of the protector parameters though, so even though the required protectors were already present, I couldn't simply enable bitlocker using the existing protectors.  To work around that, I ran it again using the RecoveryPasswordProtector option.

Enable-BitLocker -recoverypasswordprotector -mountpoint c: -encryptionmethod AES256

Finally, bitlocker was successfully enabled.  Powershell helpfully provided the recovery password again and instructed me to save it in a safe place, and instructed me to restart the computer for a hardware test before encryption begins.  The restart can be avoided if necessary by using the -skiphardwaretest parameter, but I wouldn't recommend it.

One unfortunate result of my mis-steps along the way is that I ended up with 3 separate Recovery Password Protectors assigned to the drive, and all 3 backed up to AD.  I will need to do further testing to determine why the additional passwords were created, but I suspect it may have happened as a result of my failed attempts with the "enable-bitlocker" command.  If you know why this happened, or if you have any questions, please leave a comment below.

Thanks for reading!

Viewing Windows Update logs in Windows 10

For many years, dating back at least to Windows XP, Windows Update has kept a text format log in the Windows directory, which could provide useful information when troubleshooting update issues.  Beginning in Windows 10, this log file (C:\Windows\WindowsUpdate.log) Is no longer used.  If you look for it in the Windows directory, you'll see that the file is still there, but is only 275 bytes, compared to the 1-2MB log files of the past.  The contents of this file now explain that it isn't used anymore, and list a powershell command to get a readable windows update log:

As you can see, there is a simple solution in the form of a new powershell cmdlet.  Simply run "get-windowsupdatelog" in powershell, and wait.  You'll see various input and output files scroll by in the powershell window as it parses the new "ETW" (Event Tracing for Windows" formatted logs, located in "c:\windows\logs\windowsupdate\".  When the cmdlet finishes, it will create a new windowsupdate.log file on the desktop:

Note that get-windowsupdatelog uses publicly available symbols to decode the ETL files and create the text formatted log.  The first time you run the command, you may have to accept terms to access Microsoft's internet based symbol store.  

If you're running a preview build, this commnand may not be able to decode the output, as the symbols for most preview builds aren't made available publicly.  In that case, you'll still get a windowsupdate.log file on your desktop, but the information in it will be less than helpful:

For more information on reading the windows update logs in Windows 10, check out KB3036646.

Wednesday, August 19, 2015

Now Available: Remote Server Administration Tools for Windows 10

Throughout the latter portion of the Windows Insider program testing of Windows 10, and continuing on since the release of Windows 10 last month, one question has been very popular: Where is the Remote Server Administration Tools package for Windows 10?

Finally, the wait is over:
Download the Remote Server Administration Tools for Windows 10

Monday, August 17, 2015

No KMS Key in the VLSC for Windows 10 for OPEN License

With the release of Windows 10, many IT workers are beginning to look into it and perhaps test it for use in their organizations.  When the time comes to set up KMS activation of the new OS however, those IT staff using Microsoft's OPEN Licensing may find that something is missing...

When I logged in to the Volume License Service Center recently to look up the KMS activation key for Windows 10 Enterprise, I was surprised to find that only Multiple Activation Keys (MAK) were listed.  Searching online, I came across this blog post from someone who ended up calling Volume Licensing support to get his KMS key, but with no explaination as to why.  After digging around a bit, I happened to come across an entry in the VLSC FAQ which explains the missing key.  

If you can't read that, it says:
I am an Open Customer and do not see my KMS (Key Management Service) key displayed on VLSC. How can I get it? 
KMS keys are no longer pre-assigned to Open agreements as use of MAK (Multiple Activation Key) keys is the preferred method for activation. 
If you are an Open Customer and need a KMS key, please request one by either calling the PA Call Center or emailing KMSADD with your business need.
For whatever reason, Microsoft is no longer generating KMS keys automatically for customers using Open licensing.  MAK keys are now considered "the preferred method for activation" and will be the only keys listed in VLSC for OPEN customers by default.  OPEN customers can still receive a KMS key, but must call or email the VL support center to have a key generated.

If you are an OPEN license customer in need of a KMS key, just send an email to to request the a key and they should be able to generate one and add it to your account.

Monday, July 6, 2015

Convert Windows 10 Pro ISO to Enterprise

For recent builds of the Windows 10 Technical Preview, when Microsoft has released ISO images of a build they have elected not to release ISO's of Enterprise Edition.  The most recent Enterprise edition ISO available is for build 10074.  While it is possible to download and install that build, then upgrade to the more recent builds using windows update, having install media for the current version would make things much easier.

The good news is, all of the bits for Enterprise edition are included in the ISO of Windows 10 Pro Technical Preview, and with a few simple commands it's possible to change from Pro to Enterprise edition.

To get started, download the latest Windows 10 Pro Technical Preview ISO.  As of the time of this writing, the image currently available is build 10162.  Extract the contents of the iso into a temporary directory.  In my example, I use D:\10162\.

From a command prompt, Create an empty directory to mount the wim file in, and mount the image:

Check the current edition and available targets that the mounted image can be upgraded to:

As shown in the output above, my image is currently Professional edition, and can be upgraded to either Enterprise or Education editions.  I'll upgrade to Enterprise using the /set-edition parameter of dism, then run dism again with the /get-currentedition parameter to confirm the change was successful:

Since the Enterprise edition requires a different product key than the Professional edition, the product key used in the image must also be updated:

Lastly, unmount the wim image, committing the changes that were made:

D:\10162 now contains the install files for Enterprise edition.  Run setup from there, or copy the files to bootable media to install a clean version of the latest Windows 10 Enterprise Technical Preview.

For reference, the commands used in the screenshots above are listed in order below:
md d:\mount
dism /mount-wim /wimfile:d:\10162\sources\install.wim /mountdir:D:\mount /index:1
dism /image:d:\mount /get-currentedition
dism /image:d:\mount /get-targeteditions
dism /image:d:\mount /set-edition:Enterprise
dism /image:d:\mount /get-currentedition
dism /image:d:\mount /set-productkey:CKFK9-QNGF2-D34FM-99QX2-8XC4K
dism /unmount-wim /mountdir:d:\mount /commit

I hope this information is helpful.  While it was written and tested with Windows 10 Technical preview, it should also work with Windows 8, 8.1, Server 2012 and 2012R2 (with minor changes), and most likely with the RTM version of Windows 10 when it is released.  More information about the DISM parameters used can be found on technet.