Find Out if an Update, Hotfix or KB is installed on a Windows Server Using Powershell

In Powershell versions 2 and above you can use the get-hotfix command to determine whether a particular update, KB or hotfix is installed on a Windows Server or client. Simply open Powershell and run the following command:

get-hotfix -id KBxxxxxx

Where KBxxxxxx is the name of the update you wish to search for.

Advertisements

Windows Backup encountered an error. There is not enough space on the disk

Under normal circumstances Windows Server Backup should manage disk space and remove the oldest backups automatically. This works fine normally but the other day I discovered that one of my servers had not been backing up due to the following error:

“Windows Backup encountered an error while writing to the backup target. Detailed Error: There is not enough space on the disk”

For a detailed explanation on how Windows Server Backup manages storage space please refer to the following link:

http://blogs.technet.com/b/filecab/archive/2011/03/14/windows-server-backup-automatic-disk-usage-management.aspx

It turns out the backup disk was so full, there was not enough space to run the backup. In order to clear the oldest backups, keeping the number of backups that you require use the following command:

wbadmin delete backup -keepversions:X

Where X is the number of backups that you want to keep. For example if you wanted to keep the last 30 backups use:

wbadmin delete backup -keepversions:30

Windows Server 2008 R2 SP1 install breaks RDP

After installing Service Pack 1 via windows update on a Windows Server 2008 R2 machine the other day, I discovered that I could no longer use remote desktop connection to access the server remotely. At first I wasn’t sure if the whole service pack installation was botched, but further testing revealed that all other functions of this server were operating normally. A quick google search showed that I was not alone in experiencing this problem, in fact there is enough information out there to solve this without another blog post from yours truly, but there is a bit of conflicting information so I thought I would document my experience to hopefully help others.

The problem manifests itself like this:

You try to RDP the affected server and it goes through the enitre logon process, and just when you think it is going to fire up the remote desktop it bombs out. An event was logged in the application log in my case event 4005 with a source of Winlogon, stating ‘The Windows logon process has terminated unexpectedly’ (shown below), although I have read of slightly different errors on other blog posts. Checking the Terminal Services logs indicate that the logon has completed successfully.

Event 4005 Source Winlogon after Service Pack 1 install on Windows Server 2008 R2

This situation it turns out, occurs when both KB2621440 and KB2667402 are applied to a system before Service Pack 1 is applied, as they effectively leave some of the RDP DLL files out of sync, specifically rdpcorekmts.dll. Now, alot of the posts I read online stated that you simply needed to uninstall the KB2777402 update, reboot, and then reapply it to solve this problem. I tried this first and it did not work. Various posts also stated that RDP started working after the removal of this patch, again this was not the case for me although I am sure it is correct in some cases.

So the fix I used in the end was this:

Firstly I uninstalled both KB2621440 and KB2667402 via Control Panel, Uninstall a Program, View Installed Updates, and then rebooted the server. I expected the DLLs to be set back to a working state at this point but this was not the case. Luckily in my case I had physical access to the server. Other posts state that the two updates can be uninstalled remotely using the following commands if you do not have that luxury:

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2667402 /quiet /forcerestart”

wmic /node:<SERVER> /user:<USER> process call create “powershell wusa /uninstall /kb:2621440 /quiet /forcerestart”

Note, that the commands above will restart the server

As RDP still didn’t work for me at this point contrary to other information, I ran:

sfc /scannow

This picked up some issues and required a reboot. After rebooting the server I was able to use RDP again. That was great, but didn’t help with the fact that the two patches that were removed were to address the Critical RDP vulnerability MS12-020. I certainly didn’t fancy not applying these patches to this server so I reapplied KB2621440 and KB2667402 via Windows Update, and rebooted the server. Thankfully after this I had a fully patched server and working RDP.

If you need to do all of this remotely and find that you still can’t RDP the server after removing the two patches using the commands above I recommend running sfc /scannow using PSEXEC:

psexec \\SERVER sfc /scannow

Then when the scan is finished performing a remote reboot using:

psexec \\SERVER shutdown -r -t 01

This should get your RDP back to a working state, and then you can reapply the removed updates. I have not corfirmed this but expect this fix will also work for Windows 7.

Which firewall ports to open to allow browsing of instance names and connections to SQL Server 2008 R2

By default Windows Server 2008 will block incoming connections to the SQL Server browser service, and to the SQL server default instance. If you are trying to connect to a SQL server instance, but are unable to browse to it under ‘network servers’ you need to open UDP port 1434. Firstly make sure the SQL Server Browser Service is started on the SQL server that you wish to advertise the instance for. Next fire up the ‘Windows Firewall with Advanced Security’ mmc snapin and create a new inbound rule. Create the rule for a port and specify the port as UDP port 1434 as shown below:

Allow incoming connections to named instances by opening UDP port 1434

To allow clients to connect the default instance and to access databases attached to that instance you will also need to open TCP port 1433. This can be done as above, by creating a new incoming rule for TCP port 1433 as shown below:

Open TCP port 1433 on SQL server 2008 R2 to allow connnections to the default instance

If desired you may wish to lock down these rules to certain profiles e.g. Domain, or even to certain subnets or hosts to help increase security. Also bear in mind that it is not best practice to have the SQL Browser Service enabled. Additional relevant SQL ports which you may wish to open can be found on the Microsoft site here:

Configure the Windows Firewall to allow SQL Server Access

These include:

TCP 1434 “SQL Admin Connection”
TCP 4022 “SQL Service Broker”
TCP 135 “SQL Debugger/RPC”
TCP 2383 “Analysis Services”
TCP 2382 “SQL Browser”

If using a named instance using dynamic ports you may wish to create a program rule with an exception for sqlservr.exe, normally found in

%ProgramFiles%\Microsoft SQL Server\MSSQL_YOUR_VERSION_NUMBER.YOUR_INSTANCE_NAME\MSSQL\Binn\

You may also wish to consider opening remote administrion ports on the windows firewall Domain Profile either through ‘Windows Firewall’ or ‘Windows Firewall with Advanced Security’ to allow access to start and stop the SQL server through SQL Management Studio:

Enable Remote Administration Port Rules in ‘Windows Firewall With Advanced Security’

 

Enable Remote Administration in the ‘Windows Firewall’

 

Always take extreme care when opening firewall ports, only opening those which are absolutely necessary in order to reduce the attack surface of your servers.

Force reboot of a remote server that has hung shutting down

I had an issue last night when a remote server that I was applying windows updates to, hung while it was shutting down. I will still able to ping the server, and access its file shares, but was unable to get RDP access. I was cursing at this point, with the prospect of a long journey the following day to investigate and bring the server back online. I then considered what other steps I could take to try and force the server to reboot remotely. I used the PSTools command psexec to see if I could still get command line access to the remote server, and fortunately I could. Next I tried to force a reboot of the remote server using psexec and the shutdown command as follows, where REMOTE_SERVER_NAME is the name of the remote server that I was trying to reboot:

psexec \\REMOTE_SERVER_NAME shutdown /r /t 01

alternatively you could use:

shutdown /m \\REMOTE_SERVERNAME /r /t 01

This returned the following error:

1115 A system shutdown is in progress

This basically meant that a system shutdown was already in progress,  and therefore the command was unable to force a reboot. In the end I used the pskill command to stop the winlogon service on the remote server to try and release whichever process wass causing the server to hang on shutdown. I should stress that this was a last resort, and not something that I would recommend doing unless essential:

pskill \\REMOTE_SERVER_NAME  winlogon

Anyway, after another few minutes the remote server did finally restart, although there are a few other things that I should mention that happened in the process. The operating system on this machine was Windows Server 2008 R2. After the server came back up (verified by ping -t REMOTE_SERVER_NAME) I tried to RDP the box again. I was able to enter my credentials and the logon process appeared to start, but after a few seconds the following message appeared on the screen:

Please wait for the Windows Modules Installer

The machine sat like that for quite some time, and then started ‘Configuring Updates’. My RDP session then abruptly ended and the server restarted itself again. Again, when it was back up I tried to RDP the server again and received the ‘Please wait for the windows modules installer message’ for a second time. Thankfully, after a few minutes and another ‘configuring updates’ message, logon continued and ther server was back up and running. On checking the event log and windows update log I was able to verify that all the updates had installed OK, and there were no other errors worthy of note. So in summary, if you want to save yourself a long trip, to most likely press a power or reset switch, you may want to try the above first.    

 

Generate a new SID on Windows Server 2008 and Windows 7

With the NewSID tool no longer supported by Microsoft for more recent versions of Windows, you may find yourself in a situation where you need to generate a new SID on a Windows Server 2008 or Windows 7 computer, and wonder which tool you need to use. I myself have run across an issue in the past in our development environment where duplicate SIDs caused a problem. Care needs to be taken when cloning Windows virtual machines, particularly if they will later be used as domain controllers.

In order to avoid any issues like this, the new preferred method to set a new SID on a Windows machine is to use Sysprep. Before running Sysprep, you may wish to verify the current SID on the sytem that you wish to modify. This can easily be done by running the psgetsid utility, which is part of the excellent Pstools developed by Mark Russinovich. The output of the psgetsid command can be seen below, showing the current machine SID:

Output of psgetsid before running Sysprep on Windows Server 2008 R2

 Next you can sysprep by running the following command:

C:\Windows\System32\Sysprep\sysprep.exe

Running Sysprep
 
On the Sysprep, screen make sure that you tick the ‘Generalize’ tick box as shown below:
 

Choose settings for the System Preparation Tool

 The Sysprep process will take a few minutes to run, and will automatically reboot the system if you chose to do so. On reboot, the following screen will be displayed. Click ‘Next’ to continue:

 

Click next to continue the Sysprep process

 After the sysprep process is complete, you can run psgetsid again to verify that a new SID has been generated for this computer:

Output of psgetsid after running Sysprep on Windows Server 2008 R2

 

 
 
 

Back Up All Group Policy Objects using Backup-GPO and the Group Policy Management Console

Here are a couple of quick methods to backup all of your group policy objects in one hit. The first uses the Powershell cmdlet Backup-GPO. On a Windows Server 2008 domain controller fire up Powershell, and issue the following command, where C:\PATH_TO_BACKUP is the path where you want to save the backup:

Backup-GPO -All -Path C:\PATH_TO_BACKUP

The second method uses the Group Policy Management Console. Fire up gpmc.msc, and then expand your domain. Right click on ‘Group Policy Objects’ and then choose ‘Back Up All’ as shown below:

Backing up all GPOs using the Group Policy Management Console

Browse for a location to back up to, and give a description if you need one, then click Back Up and you’re done:

Choose a location and description for the GPO backup

 

References:

http://technet.microsoft.com/en-us/library/ee461052.aspx