Windows 7 SP1 installation fails with error 0x800f0818

I came across a peculiar problem today trying to install SP1 on a Windows 7 laptop. Whenever I ran the Windows 7 SP1 installer or tried to update to SP1 using Windows Update the installation failed with a cryptic error ‘0x800f0818‘. I tried various things such as running sfc /scannow and installing the Windows 7 System Readiness Tool (64 bit in my case), but neither reported problems.

After a bit of digging I found an entry in the CheckSUR log file found in C:\Windows\Logs\CBS which seemed to be related. In this case a .Net Framework update had failed to install a few times and this particular update was referenced in the log file:

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs (f) CBS MUM Corrupt 0x00000000 servicing\Packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~  Expected file name Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Summary: Seconds executed: 485  Found 1 errors   CBS MUM Corrupt Total count: 1

Unavailable repair files:  servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~  servicing\packages\

To fix the problem I had to remove entries for the corrupt package from the registry (IMPORTANT: taking a backup first) from:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages

The specific entries are shown below. There are two, the highlighted entry, and the one beneath:

Deleting corrupt package entries from the registry


After deleting the two entries I reran Windows Update checking for updates and this package was redownloaded and then installed without issue. After this the service pack 1 installation proceeded without error. You may find that the specific update referenced in your CheckSUR log is different to the one mentioned here, but the method is the same.

Allow popups from certain websites using a group policy object

If you need to allow pop ups from specific websites when using Internet Explorer in your environment, you can enable them by using the ‘Pop-up allow list’ setting in the relevant group policy object (GPO).

Simply edit the relevant GPO, adding the addresses of web sites that you wish to allow pop ups for. The setting can be found under:

Computer Configuration, Administrative Templates, Windows Components, Internet Explorer, Pop-up allow list


User Configuration, Administrative Templates, Windows Components, Internet Explorer, Pop-up allow list

Allow pop ups in Internet Explorer using the ‘Pop-up allow list’ setting in a group policy object

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


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.

Using and verifying HTTP compression on aspx pages in IIS 6

Yesterday I was examining some performance issues with an in house web application over our wide area network. While a developer looked at the code I thought I would see what could be done with http compression. This particular application is hosted on IIS 6 which is unfortunate as there some improvements with http compression in IIS 7. Anyway to enable http compression for aspx or other associated web pages in IIS6 you need to do the following. Firstly enable http compression on the server by right clicking on the ‘Web Sites’ folder in IIS Manager and choosing properties:

Accessing web sites properties

Next, click on the ‘Service’ Tab and check the ‘compress application files’ and ‘compress static files’ tick boxes and then choose a limit for temporary files. Then click OK

Next, download and install the IIS 6 resource kit tools from Microsoft which can be found here. Once the tools are installed open ‘Metabase Explorer’ and navigate to LM, W3SVC, Filters, Compression, deflate. Add the file extensions you wish to compress to HcScriptFileExtensions, in this case aspx, axd, asmx and css. Then change the HcDynamicCompressionLevel to a value between 1 and 10, 1 for low compression with low CPU utilisation, and 10 for high compression with high CPU utilisation. Setting this to a high value such as 9 may not necessarily give that much higher compression than choosing 5, so be careful to choose a value which is a good balance between compression and performance. Then apply identical settings for HcScriptFileExtensions and HcDynamicCompressionLevel  under LM, W3SVC, Filters, Compression, gzip

Modifying HcScriptFileExtensions and HcDynamicCompressionLevel in Metabase Explorer

 Save the configuration in IIS manager and then perform an iisreset from the command prompt.

You can verify the amount of compression you are are getting using a tool such as Fiddler or alternatively browser plugin Httpwatch.

To do this using Fiddler, download and install Fiddler and then run the program. Then access the website as normal, accessing some of the pages that you are attempting to compress. Once you have some entries in the ‘Web Sessions’ pane, click on the page you want to view the compression stats for in the list. The number in the ‘body’ column is the compressed size. In the bottom right section of Fiddler, click on ‘Transformer’ and you will see the compression type:

View compression status in Fiddler

View compression status in Fiddler

You will notice the yellow bar above the ‘transformer’ tab which says ‘Response is encoded and may need to be decoded before inspection, click here to transform’. Click on the yellow bar:

View original entity size before compression status in Fiddler

On this screen examine the ‘Entity Size’ which will be the original size of the page before compression. You can compare this to the body column to see the amount that the page has been compressed, in this case around a 27% saving on bandwidth.

FRS or DFSR not replicating certain files

I had an issue today where a file that I had added to the SYSVOL share on my network, hadn’t been replicated to other domain controllers. The file was a jpeg that had been created by our designer, which needed to be pushed out to client computers using group policy preferences. I modified the GPO last week, but noticed this morning that the file wasn’t being to copied to all client computers. I had a look at the location where I had created the file in the SYSVOL share on various domain controllers, and found that the file hadn’t been replicated to any of them. In fact, it was only present on the server that I had originally copied it to.

I checked the logs on a few of the domain contollers for errors with the File Replication Service, but there were none. Next I created a test text file in the SYSVOL share to see if it replicated to other domain controllers and it replicated straight away. On further investigation I discovered that the temp attribute had been set on the jpeg file for some reason when it was created, and therefore it was being ignored for the purposes of replication by FRS, which is the standard behaviour, and also applies to DFSR.

You can’t view the temp or ‘T’ attribute using the attrib command, so a grabbed a utility called BulkFileChanger which verified this and allowed also allowed me to quickly remove the temp attribute. I then recopied the file to the SYSVOL share and it replicated to the other servers as normal.

Alternatively, you could use fsutil to discover the current attributes set on the file or files, and then use powershell to reset the attributes as outlined in the technet article below.    



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:


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