WSUS repair after backup restoration

Last week during the process of updating a few services one of the WSUS servers had gone belly up. Installing over the top or performing an uninstall then a re-install did not clear up the issue. The next step was to perform a restore on the system (dedicated WSUS/Forefront for Exchange VM) from the last backup taken before the system started going south. The restore worked bringing back a WSUS instance which would talk to the clients without any issues but then I started seeing errors in the application event log. The errors were showing that recently approved updates which were in the database could not be found on the filesystem.

What I ran into was a catch-22 when performing an enterprise deployment of WSUS where the SQL instance is on another VM separate from the WSUS server. Restoring the SQL database is possible but it may or may not be exactly when the backup of the WSUS instance was so I opted the other option which allows for the existing database to remain intact.

1) Stop the “Update Services” and two IIS services
2) Delete everything found in the WsusContent folder, while it can be skipped I wanted to make sure everything was cleanly downloaded
3) Open up a command line
4) cd “\Program Files\Update Services\Tools
5) wsusutil.exe reset

This will issue a full verification of the WSUS installation and pull down all of the approved updates. Which at this point the 30GB or so of updates took a few hours to rebuild the entire local cache. At which time, updates began to flow normally.

, , , , ,
August 24, 2012 at 9:42 am Comments (0)

Hiding Distribution Group memberships

Under Exchange 2010 the need arose to create some distribution groups which the membership was hidden. The most published method is to actually use two groups. The first is a non-mail enabled group and the second is a dynamic distribution group. While these do have there place in many organizations I wanted to maintain the same functionality without needing the second group.

To keep my life simple here is the PowerShell method to this problem.

Lets define some variables

$listname = "allemployees"
$orgunit = " Groups"
$managedby = "MyDummyAdmin"
#Build the Group
New-DistributionGroup -Name $listname -SamAccountName $listname -OrganizationalUnit $orgunit -Type "Distribution" -ManagedBy $managedby -MaxReceiveSize "5120 KB"
sleep 4
#Restrict commandline to view membership via net group command
Add-ADPermission -Identity $listname -User "Normal_Employee_Group" -Deny -AccessRights ReadProperty -Properties Member
#Restrict Outlook & OWA Access to view membership
set-ADGroup -identity $listname -Replace @{HideDLMembership=$true}

This method has been used in the past via ADSI Edit but I was looking for a native PowerShell approach for a process to automate group creation.

The only drawback is the HideDLMembership is organization wide, so regular managers cannot see the group memberships. Administrators can still see membership via the EMS, EMC, or via the old net group method.

, , , ,
August 12, 2012 at 9:00 am Comments (0)