Month: October 2011

Thoroughly cleaning up a WSUS server

John 3 Comments

I was recently tasked with performing a clean-up of some of our servers, removing old files/software installations as well as a clean-up of our WSUS server.  After a quick look I could see that our previous administrator had set it to download Driver updates as well, which was taking up quite a large amount of space and something that we wern’t really looking at using (no driver updates were approved).

So I ran the WSUS clean-up wizard, which removed some old computers, but the driver updates remained. I wanted them gone.  So I quickly made sure that driver updates category wasn’t selected and ran the following PowerShell script on the WSUS machine.

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
$cleanupScope.DeclineSupersededUpdates = $true
$cleanupScope.DeclineExpiredUpdates         = $true
$cleanupScope.CleanupObsoleteUpdates     = $true
$cleanupScope.CompressUpdates                  = $true
#$cleanupScope.CleanupObsoleteComputers = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope);

This script took about an hour to run but worked like a charm. It basically cleaned up the whole WSUS database, removing old computers, obsolete and unneeded updates (including the drivers I no longer wanted) as well as removing the associated update files which cleaned up a lot of space. The script above is modified so as not to remove computers from the database but that can be simply uncommented and included in the script.

Let me know in the comments if you found this useful.

Procurve Switches and Windows Network Load Balancing in Multicast Mode causing high collision and drop rates

John 5 Comments

Over the last few days we have been looking at getting a Client Access Array going for our Exchange 2010 setup for basic redundancy and load balancing. I thought I would outline an issue we discovered with using Windows Network Load Balancing in a HP switching environment.

The first is whether to use Unicast or Multicast modes for the NLB Traffic. It is important to remember that Exchange does not care if you use Unicast or Multicast and is entirely dependent on your switching environment. At first we were confused as to which to choose due to the myriad of documentation suggesting either protocol. So we decided to give multicast a go.

After a few minutes our core switch (an 8212zl) started dropping packets for our services VLAN. We shut off the NLB and everything had returned to normal.  After a bit of digging we found that ProCurve switches are not compatible with multicast mode NLB due to their inability to have static ARP tables (they can only cache). But this can be remedied somewhat by issuing the following command on some models of switches:

ProCurve(config)# ip arp-mcast-replies

The command is supported on HP ProCurve E8200zl series, E5400zl series, E3500yl series, E6600 series and E6200yl series switches support Microsoft Windows NLB in Multicast mode.  Simply ensure that these switches are running K.15.03.0007 or greater firmware.

Setting up an SPN and fixing the cannot verify the service principal name error when installing ForeFront Endpoint Protection

John 1 Comment

We are currently in the process of trailing Forefront Endpoint Security along with our SCCM Deployment.  So after a few weeks of tweaking we have got our systems center deployment to a level where we are happy with it, it was time to begin installing and testing Forefront.

After beginning our installing and answering a few questions the setup begins to validate some per-requisites. Apart from having reporting services installed and configured on a SQL Server you also need to have the service account for SQL Server to be publishing its existence via a Service Principal Name or SPN. If the account doesn’t have a valid SPN entry then you will receive the following message during the per-requisites check of the Forefront setup.

Setup cannot verify the service principal name (SPN) for this account.
Ensure that there is a single valid SPN entry for this account in the
Active Directory Domain Services.

So how do we go about adding an SPN entry. We will use sqlservice as our user account. We can either do this via ADSIedit or the command prompt. Open up an elevated command prompt and enter the following command:

setspn -a MSSQLSvc/sqlserver.fqdn domain\sqlservice

with MSSQLSvc being the protocol, sqlserver the name of the Server hosting SQL Services along with your fully qualified domain name and finally the account you wish to add the SPN entry for. To check that you have successfully added the spn you can do the following:

setspn -l domain\sqlservice

which will list the account along with SPNs being advertised for that particular account.

The quicker way would be to run ADSIedit, find the account you wish to add the SPN for, right click and go properties and then under the attribute editor. From there navigate down the list until you find servicePrincipalName and click edit. You can then enter the SPN in the same format as above, which is:

MSSQLSvc/sqlserver.fqdn

And there you have it, you can continue to install Forefront without any issues so long as you meet the other requirements of the setup.

Fixing SMS Site Component Manager could not access site system. Access is denied. Issue when adding SCCM components to other servers.

John 2 Comments

I recently decided to move our reporting services running on our SCCM site server to our more beefier SQL Server, I was also wanting to do this for our Forefront Migration (as Reporting services is a requirement). So I created a new server under Site Settings -> Site Systems and put our SQL server into there. I then added the ConfigMgr Reporting Point and Reporting services point with SCCM adding in Component Server and Site System into the roles.

After a little while I then checked the Site Component Manager logs and found the following error:

SMS Site Component Manager could not access site system "<servername>".
The operating system reported error 2147942405: Access is denied.

So I went looking to make sure that the server was up, and our Administrator account had local machine rights, it was there.

After some further investigation I also found out that the SCCM site server also needs administrative rights, so I added the computer to the local administrator group and restarted the site component manager to force it to retry installing the components and the error disappeared and SCCM began installing the components onto our SQL Server.