Why you shouldn’t remove .NET in Windows Server

Posted on by Glenn

Good afternoon.
The rumors of my demise have been greatly exaggerated. It is time for another interesting issue. I have seen this issue a few times now, but this last time I was finally able to put my finger on the cause and correct it. The issue in this case occurs when the .NET Framework 4.7 Features are removed from Server Manager. See the picture below.

There is a whole slew of issues that will come up by removing .NET. One of which is that Server Manager and PowerShell no longer function. See below for a couple of errors that can be encountered.

The code execution cannot proceed because mscoree.dll was not found. Reinstalling the program may fix this problem.
The code execution cannot proceed because mscoree.dll was not found.
MMC could not create the snap-in. CLSID: FX:{b05566ad-fe9c-4363-be05-7a4cbb7cb510}
MMC could not create the snap-in. CLSID: FX:{b05566ad-fe9c-4363-be05-7a4cbb7cb510}

So this should be easy to fix. Just fire up Server Manager… Well that would be great if it worked. No problem, I know a fancy PowerShell command. Shoot, that doesn’t work either. Don’t fret though. There is a tool that has been with Windows since 2008 and still works to add or remove a feature. The tool is dism. Here are the steps to get .NET and PowerShell put back.

  1. Right-click the Start button and choose the Run option.
  2. Type cmd and press enter.
  3. Run the command: dism /online /enable-feature /featurename:NetFx4ServerFeatures /ALL and press return.
  4. Type PowerShell and press enter.
  5. Run the command: Install-WindowsFeature PowerShellRoot,PowerShell,PowerShell-ISE.
  6. Restart the server.

After running through the above the server should function normally again. I tested this process in Windows Server 2019, but should also work in Windows Server 2016 also.

I hope you found this article informative. If you have anything to add please feel free to leave a comment below.

The bootfile is too small to support persistent snapshots

Posted on by Glenn

Good afternoon. It has been too long since I last posted. Today I found a solution to a problem I have seen several times and I wanted to share it.

I had a customer that was experiencing backup issues with a new load of Windows. When trying to backup the server in Windows Serer Backup the backup would always fail with the error “Windows Backup failed to create the shared protection point on the …”. An important point to note is the error would always occur during the VSS snapshot phase of the backup.

Below is the resulting Application event log with the key event highlighted.

At this point it is probably helpful to get a high level overview of how Windows Server Backup and VSS work. When Windows Server Backup starts a backup one of the first steps is to call VSS to take a snapshot. When the backup destination is local disk, the request is for both the backup destination and the backup source. This is so that Windows Server Backup can compare the blocks in both to perform an incremental backup. This means that a failure to snap the source or destination can cause the backup to fail.

I have seen this issue a handful of times and the consensus was the backup drive was causing the problem. While this can be the case, today I learned how to pinpoint which volume is actually causing this error with the event log. The key to determining this is the volume GUID ( Globally Unique Identifier) specified in the description of the event. This is the volume that cannot be snapped by VSS and is causing the backup to fail.

So how do you take the GUID and get the drive letter? This is the easiest part. Simply open an admin cmd window and run the command “mountvol”. At the end of the output all volumes with GUIDs and drive letters will be listed. In our case it was the D:\ drive that contained user data. We ran a test backup excluding the D:\ drive and it completed with no errors.

How do I fix the volume, so it will backup? Obviously we will not want to exclude a volume from the backup. There are two methods to repair this issue. First a chkdsk /f can be run to attempt and repair the volume. If that fails though, then you are likely looking at a bit of work to recreate the volume. Here is the process:

  1. Backup the data with robocopy or another file level backup utility. For robocopy an example command: robocopy <source> <destination> /MIR /XJ /W:5 /R:3 /LOG+:c:\robolog.txt
  2. Run diskpart and “clean” the disk. To do this run diskpart at an admin cmd, select the problem disk, then run the clean command.
  3. Recreate the volume
  4. Restore the data with robocopy or whatever file level backup utility used previously.

I hope you have found this post informative. If you have another way to solve this problem I would love to hear about it in the comments.

Windowsupdate.log is filled with GUIDs

Posted on by Glenn

Good afternoon. I found an interesting solution I wanted to share. I needed to collect the Windowsupdate.log file on a Windows 2016 server today. To do this I needed to run the PowerShell command Get-WindowsUpdateLog. The file is no longer continuously created as with previous Windows versions. This is all well and good, if the command worked 100% of the time. There have been some instances though where I ran that command and just get a file filled with GUIDs. See the example below.

1600/12/31 18:00:00.0000000 824 1056 Unknown( 10): GUID=638e22b1-a858-3f40-8a43-af2c2ff651a4 (No Format Information found).
1600/12/31 18:00:00.0000000 824 1056 Unknown( 11): GUID=bce7cceb-de62-3b09-7f4f-c69b1344a134 (No Format Information found).
1600/12/31 18:00:00.0000000 824 1056 Unknown( 11): GUID=638e22b1-a858-3f40-8a43-af2c2ff651a4 (No Format Information found).
1600/12/31 18:00:00.0000000 824 1056 Unknown( 50): GUID=6ffec797-f4d0-3bda-288a-dbf55dc91e0b (No Format Information found).
1600/12/31 18:00:00.0000000 824 1056 Unknown( 12): GUID=00497b4f-20f7-3ec8-96ab-8a593aa9824d (No Format Information found).

I have always wondered why this happened. I finally discovered the answer today. When I ran the PowerShell command I kept getting a popup about website security. I checked the box to not ask again and clicked OK. I then received a file full of nothing useful. I had a hunch that the command needed to grab information from the Internet to decode the GUIDs. Perhaps IE ESC (Internet Explorer Enhanced Security) was causing an issue with that process. I disabled IE ESC and re-ran Get-WindowsUpdateLog. Sure enough the file was created correctly.

So now you know. If you get a Windowsupdate.log file full of GUIDs there are two items to check. Verify the server has Internet connectivity and that IE ESC is turned off.

I hope you found this article informative. If you have anything to suggest or add to the content, please leave it in the comments below.

User profile corruption for Windows service accounts

Posted on by Glenn

Good morning. It has been a while since I posted, so I figured it was time for another article. I ran across an interesting issue this morning that I figured I would share. I had a customer that had recently experienced some file system corruption on the C: drive. Luckily chkdsk was able to correct the issue, but there was an issue that cropped up after running it. My customer was seeing an error in the Windows system log coming up frequently. The error was a 7005 with a source of Server Control Manager. The description was his concern though.
“The LoadUserProfile call failed with the following error:
The configuration registry database is corrupt.”

I did some research on this error and it is caused by a corrupt user profile. I figured it was probably a service user account as we had several services starting within seconds of each occurrence. Through a process of elimination I discovered that starting any service using the Network Service as the logon service caused the error.

So now I knew which account was causing the error, but how do you recreate the user profile for the Network Service user? I first checked the c:\users folder and the profile is not there. It is also not in the user profiles list in the system properties. I checked the registry as it has a list of all users with profile locations.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Bingo!

The Network Service profile is located in C:\Windows\ServiceProfiles\NetworkService. I renamed the profile in the registry (S-1-5-20) to S-1-5-20.old and the NetworkService folder to NetworkService.old.

I then started a service that used the Network Service account, and success. The registry key was recreated, as was the folder, and we received no errors in the event log.

On a side note the above process will also work for the Local Service account. Just rename the appropriate registry key and folder.

I hope you found this article informative. If you have anything to add or would like to suggest an edit, please do so in the comments below.

Problems installing RDS CALs on a 2019 license server

Posted on by Glenn

Good morning.  I had an interesting issue this morning I figured I would share.  I had a customer that was having a tough time installing his RDS CALs.  At both activate.microsoft.com and in the install license wizard we were receiving the error “Invalid license code” and “The serial number is not valid.” respectively.  I assumed this was due to a bad license code, as I have seen that a couple of times in the past.  After emailing Microsoft, I was able to confirm the license code was good. 

The serial number is not valid.

After going back to my customer, I found out that the license server was running Windows 2019.  Normally this should not be a problem as you can install down-level CALs.  For instance, it is possible to install 2012 RDS CALs on a 2016 license server.  It appears that may no longer be the case with 2019 or this may be a bug.  Time will tell.  In the end we fixed the problem by installing licensing on the Windows 2016 server.  The CALs then installed without issue.

If this changes in the future I will update this blog post.  I hope you found this blog post useful.  If you have any corrections or anything to add, please do so in the comments below.

Windows Server Essentials wizard failing at 16%

Posted on by Glenn

Good morning.  I wanted to document an issue I have seen several times.  The fix for this problem is pretty easy in PowerShell, but would take quite a bit of time using Server Manager.  The reason for the wizard is failing at 16% is due to the inability to connect to a domain controller in the domain.  This failure to connect is due to none of the roles being installed and therefore the server not being promoted to a domain controller.  This can all be discovered from the Essentials deployment logs in the C:\ProgramData\Microsoft\WindowsServer\Logs folder.

As I stated above the fix is pretty easy.  Run the three PowerShell commands below, changing domainname to the name you want for your domain and the P@ssW0rD! to a password of your choosing.  Keep in mind this password must meet complexity requirements with a length of at least 8 characters and 3 of 4 character types; capital letter, lowercase letter, number, special character.

NOTE: If you do not want the default computer name of WIN-<random string>, then you should change the computer name via the sysdm.cpl application or use netdom.
Also, change domainname.local to a domain name of your choice that ends in .local.  For instance tailspintoys.local or contoso.local.  You will not be able to change the computer or domain name after completing the wizard.

Install-WindowsFeature AD-Domain-Services,DNS,FileAndStorage-Services,File-Services,FS-FileServer,FS-BranchCache,FS-DFS-Namespace,Storage-Services,NPAS,RemoteAccess,DirectAccess-VPN,Remote-Desktop-Services,RDS-Gateway,Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Http-Redirect,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Security,Web-Filtering,Web-Basic-Auth,Web-Client-Auth,Web-IP-Security,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-ASP,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Web-Scripting-Tools,ServerEssentialsRole,NET-Framework-45-Features,NET-Framework-45-Core,NET-Framework-45-ASPNET,NET-WCF-Services45,NET-WCF-HTTP-Activation45,NET-WCF-TCP-PortSharing45,BranchCache,GPMC,RSAT,RSAT-Role-Tools,RSAT-AD-Tools,RSAT-AD-PowerShell,RSAT-ADDS,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,RSAT-ADCS,RSAT-ADCS-Mgmt,RSAT-DNS-Server,RSAT-NPAS,RSAT-RemoteAccess,RSAT-RemoteAccess-PowerShell,RPC-over-HTTP-Proxy,FS-SMB1,Windows-Defender-Features,Windows-Defender,Windows-Defender-Gui,Windows-Internal-Database,WAS,WAS-Process-Model,WAS-Config-APIs,Search-Service,Windows-Server-Backup,WoW64-Support

$Password = ConvertTo-SecureString “P@ssW0rD!” -AsPlainText -Force

Install-ADDSForest -DomainName “domainname.local” -SafeModeAdministratorPassword $Password -Force

After the above commands complete the server will automatically restart and the deployment wizard should complete without further errors.  If it is failed, then click Retry.  I have seen a few instances where a retry is necessary.

I hope you found this post helpful.  If you have anything to add, please do so in the comment section below.

Some settings in Windows 2016/10 giving an error

Posted on by Glenn

Good afternoon.  I ran into an interesting issue I figured I would share.  I had a customer that would receive the error below when clicking on some settings in Windows, for instance the change adapter options in the network section of settings.

user profile error

I did quite a bit of searching for a possible solution and I found quite a few forum posts and self-help guides, but none had the solution.  I broke out a tool I use from time to time to see I could figure out why Windows cannot access the device, path, or file; Process Monitor.  I ran a capture while duplicating the issue.  In pouring over the results I found a possible culprit in some registry paths in the HKCU registry hive.  It turns out that these setting options look at paths stored in the registry when clicked.  Unfortunately for my customer he was missing some paths and so Windows could not find the file.

To confirm this was the issue I created a copy of the administrator account and we logged on with that account.  Sure enough, no errors.

To fix the issue we simply deleted the user profile for the problem account.  This can be accessed by running sysdm.cpl, going to the Advanced tab and clicking user profiles Settings button.  After deleting the profile, we then logged the test account off and logged on with the administrator account and presto, no more errors.

I hope you found this article informative.  If you have anything to add or just want to comment, please do so below.

Performing a bare metal restore with Windows

Posted on by Glenn

Good morning.  I had a question today on what to do if the hard drives are not detected when performing a bare metal restore.  Loading the driver is pretty straightforward, but I could not find a good guide on the whole process, so I figured it was time to put one together.  Below I will outline with screenshots the process to do a bare metal restore.  The screenshots will be from Windows Server 2016, but the process is the same for all currently supported versions of Windows.

  1. We start by booting to the Windows media.  After selecting the language, you have two options; Install now or Repair your computer.  Choose Repair your computer.
    2
  2. The next screen may give you more or fewer options.  Choose Troubleshoot.
    3
  3. From the Advanced options screen, choose System Image Recovery.
    4
  4. If given the option for a target operating system, choose the one applicable to you.
    5
  5. On the following screen, you will have two options; Use the latest image or select a system image.  If you want to restore the latest backup, then you simply need to click next.  If however you want to restore an earlier backup, choose the option to select a system image.  This guide will continue with the second option.
    7
  6. If you have only one backup drive, then only one line item will show.  A line for each backup drive will be displayed on this screen.  Choose the backup drive to restore from and click Next.
    9
  7. On this screen all the available backups are displayed to restore from.  Select the preferred backup to restore and click Next.
    10
  8. This screen provides three important options.  The first is to format and repartition the disks.  Select this option to completely wipe the drive being restored to.  It is possible to exclude data drives from this by clicking the exclude drives button and checking the drive to exclude.  The second option will only restore the system drives.  Keep in mind though, if the page file was moved a data drive, that drive is now considered a system drive and has to be part of the restore.  The last option is to install drivers.  Do this if the drives being restored to are not detected by the restore wizard.  Once all desired options are selected, click Next.
    12
  9. This screen is a summary of the restore.  Click Finish to start the restore process.
    14

After clicking yes on the prompt, the rest of the process is automated.  The server will be restored and automatically boot back into the restored Windows OS.

I hope you found this post informative.  If you have anything to add or suggest, please do so in the comments below.

Error 1202 from DFSR

Posted on by Glenn

I ran across an interesting issue I wanted to share.  I had a customer that recently had a migration performed.  Previously he was running SBS (Small Business Server) 2011 and is now running Windows Server Essentials 2016.  After demoting and removing the SBS 2011 server, he started receiving the following error on every boot.

1202 DFSR

The error is quickly followed by an informational message indicating that DFSR (Domain File System Replication) successfully connected to a domain controller.

Based on my previous experience with similar issues I posited that the problem was due to the DFSR service starting before either the network stack was fully initialized or before the DNS (Domain Name System) service was running.

I explained that based on the behavior this could safely be ignored.  This did not go over very well as the error also shows up in the Windows Essentials health report.  This brings us to the solution.  And this solution will work for just about any service that needs a little more time at boot.  We set the startup type for the DFSR service to Automatic (Delayed Start).  We restarted the server and this eliminated the 1202 error.

I hope that you found this article informative.  If you have anything to add, please feel free to leave a comment below.

The diskshadow command, a hidden gem

Posted on by Glenn

Good morning.  In case you haven’t guessed it already I typically write these posts in the morning.  As I write this now it is 6:30AM.  Today I wanted to share a command line utility I just recently discovered.  It has been part of Windows for quite some time though.  At least since Windows Server 2008.  The utility is called diskshadow.  This utility allows direct interaction with VSS (Volume Shadow Copy Service).  You can find the Microsoft technet article here.  In this article I will go over how I used it to troubleshoot a recent issue with VSS.

I was recently troubleshooting a VSS where the snapshot was failing on release.  As is typical, my customer was using a 3rd party backup software.  I wanted to test outside of the backup software, so we installed the Windows Server Backup feature and tried that.  Unfortunately the symptoms were identical.  After quite a bit of digging I ran across the diskshadow utility.  With that utility I received a different error which led me down the path of discovering the problem.  It turned out that the backup software’s filter driver was stepping on VSS and causing the failure.  After removing the backup software, VSS worked without issue.

So how is the diskshadow command used?  It can be used to create a snapshot, mount an existing snapshot, restore a snapshot and several other things.  Below I will cover the commands to take a VSS snapshot, as that is the functionality I find most useful.  To take a snapshot of the C: drive and test the majority of the VSS writers there are just 3 commands that need to be run.

  1. diskshadow (This starts the command and puts you at a diskshadow prompt.  This is similar to ntdsutil and nslookup.)
  2. add volume c: (This adds the C: drive to the snapshot.  You could substitute another drive letter if you want to test a specific writer.  The command can also be repeated with other drive letters to include them in the snapshot.)
  3. create (This starts the snapshot process with VSS.  It is important to note that the create command by itself will create a non-persistent snapshot.  That is the snapshot will be removed on exit from the diskshadow utility.  A persistent snapshot can be created with additional parameters.)

This utility is considerably faster when troubleshooting VSS, taking only about 1-2 minutes to take a snapshot or fail.  It also removes the requirement for a USB drive to temporarily store a backup.  For these reasons I will be using whenever troubleshooting VSS in the future.

I hope you found this article informative.  If you have anything to add or just want to leave a comment, please do so below.