Windows Server 2012 – WSUS Post-Install Tasks Fail Immediately

Not long ago, I was trying to re-install WSUS on a server that would not generate the ‘WSUS Administration’ website.

Post-installation tasks would also fail without giving me much to go on. After some time researching, I found several posts on message boards that all said to do different things to resolve the issue. Some of them even said to either reload the OS on the server (not always an option in a production environment), or call Microsoft for help (which as we all know costs $$$).

Here’s what I found…

In the installation log located in the %temp% folder there should be a log file with the .TMP file extension. (EXAMPLE: tmp56B7.tmp)

When looking at this file, it told me that a file it was looking for was not found, or corrupt.

When I ran the WSUS Console I saw the following:

___________________________________________________________________________

The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,

Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.

The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,

Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.

System.NullReferenceException — Object reference not set to an instance of an object.

Source

Microsoft.UpdateServices.UI.AdminApiAccess

Stack Trace:

at Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetLocalInstallDir()

at Microsoft.UpdateServices.UI.AdminApiAccess.Constants..cctor()

** this exception was nested inside of the following exception **

System.TypeInitializationException — The type initializer for ‘Microsoft.UpdateServices.UI.AdminApiAccess.Constants’ threw an exception.

Source

Microsoft.UpdateServices.UI.SnapIn

Stack Trace:

at Microsoft.UpdateServices.UI.SnapIn.Scope.RootScopeNode.GetComputerTargetFromCmdLine()

at Microsoft.UpdateServices.UI.SnapIn.Scope.RootScopeNode.AddServerScopeNodeFromCmdLine()

at Microsoft.UpdateServices.UI.SnapIn.Common.SnapInManager.OnLoadCustomData(AsyncStatus status, Byte[] persistenceData)

___________________________________________________________________________

To resolve the issue, I performed the following steps (in order):

1) Open a PowerShell session as Administrator and uninstall WSUS completely with the following command:

Remove-WindowsFeature –Name UpdateServices,UpdateServices-DB,UpdateServices-RSAT,UpdateServices-API,UpdateServices-UI –IncludeManagementTools

2) Delete the registry key HKLM\SOFTWARE\Microsoft\Update Services

3) Delete the WSUS file from %appdata%\Microsoft\MMC

4) Delete the Folder %ProgramFiles%\Update Services along with all of its subfolders and files.

5) Reboot the server

6) Run the System File Checker to find and repair any inconsistencies by typing the command below into the PowerShell prompt.

SFC /scannow

7) Reboot the server

8) Verify IIS is installed and working without errors

9) Open a Powershell session as Administrator an install WSUS with the following command:

To use a SQL DB:

Install-WindowsFeature –Name UpdateServices,UpdateServices-DB -IncludeManagementTools

To use WID:

Install-WindowsFeature –Name UpdateServices –IncludeManagementTools

10) Once WSUS installation has completed, change the current working directory to %programfiles%\Update Services\Tools and run one of the following post-installation commands:

To use a SQL DB:

.\wsusutil.exe postinstall SQL_INSTANCE_NAME=”SERVER\Instance” CONTENT_DIR=”<drive>:\WSUS”

To use WID:

.\wsusutil.exe postinstall CONTENT_DIR=”<drive>:\WSUS”

11) Wait for the command to complete successfully.

12) If you are using this WSUS instance as part of a farm, then open the Admin Console and configure your updates.

13) If you are using this instance as part of the roles within an SCCM Implementation, open the SCCM Console and install the Software Update point role.

Configure as needed and happy patching!

Advertisements

Add Affected User to AAW Requests using Orchestrator Runbooks or PowerShell

As some of you may know, the requests generated in Service Manager through the Application Approval Workflow (AAW) Solution Accelerator do not set the Affected User in the Request.

I’ve recently implemented the solution for one of my customers and it was requested that users submitting these application requests be able to view them from the Service Manager Self-Service Portal (SSP).

However without the Affected User relationship being defined with the work item, the only place to view the application request status is by going to “My Requests” in the Application Catalog page from ConfigMgr. I was tasked with setting the “Created By” user as the “Affected User” so that when an application is requested, it will show up in their My Requests section of the SSP.

After some research, it was fairly difficult to find any in-depth documentation on how this may be performed. So, it was up to me to get it done.

Subsequently, I was able to create a PowerShell script, and an Orchestrator Runbook.

Below is a link to my SkyDrive for downloading the files. Please use and comment if there are any suggested modifications/ changes.

The script requires the SCSM PowerShell Cmdlets (SMLets). They can be found at http://smlets.codeplex.com

 

Download Files Here

Changing Service Account Passwords for SCSM

Recently I was asked about what the process was for updating service account passwords for Service Manager. Directions for this can be found on TechNet at the links below.

Typically in an enterprise environment, there are password policies that require expiration and update of passwords. This can be user accounts like those you and I regularly use for our day to day activities on the job. Other user accounts are called service accounts. As many of you know, if an account password for a particular service is expired, or changed without updating the service we end up with an outage of that service within our infrastructure.

To help prevent these outages, we need to update the passwords for service accounts wherever they are used. In Service Manager, there are a few accounts that are used. The accounts listed in the tables below may not be the same as those you have used, but I’ll bet that there is an equivalent in use within your Service Manager Implementation. Some of these may even be combined into a single account for ease of use or simplification.

To update the credentials used, follow the steps outlined in TechNet (links above).

 

Table 1 – SCSM Service Accounts

Account Name

Description

Permissions

SCSMSA

Service Manager – Service Account

Local Admin on Service Manager Server(s). Must be same account for Data Warehouse and Management Servers.

SCSMRA

Service Manager – Reporting Account

Granted Rights within SQL During installation.

SCSMAS

Service Manager – Analysis Services Account

Granted Rights within SQL During installation.

SCSMWF

Service Manager – Workflow Account

Local Admin on Service Manager Server(s). Must be same account for Data Warehouse and Management Servers.

 

Table 2 – SCSM Data Connector Accounts

Account Name

Description

Permissions

SCSMADCON

Service Manager – Active Directory Connector Account

Active Directory – Read

Advanced Operator in Service Manager

SCSMOMCICON

Service Manager – Operations Manager Configuration Item Connector Account

Operator Privileges in Operations Manager

Advanced Operator in Service Manager

SCSMOMALCON

Service Manager – Operations Manager Alert Connector Account

Administrator Privileges in Operations Manager

Advanced Operator in Service Manager

SCSMCMCON

Service Manager – Configuration Manager Connector Account

smsdbrole_extract & db_datareader roles in Configuration Manager Database

Advanced Operator in Service Manager

SCSMSCOCON

Service Manager – Orchestrator Connector Account

Read Properties, List Contents and Publish permissions to the root Runbook folder and all child objects. Grant via the Runbook Designer.

Advanced Operator in Service Manager

SCSMVMMCON

Service Manager – Virtual Machine Manager Connector Account

Administrator in Virtual Machine Manager

Local Administrator on Virtual Machine Manager Server

Advanced Operator in Service Manager

 

If you need to create a new Run As Account with Service Manager, it can be done using PowerShell. I’ll save that for another post.

SCSM 2012 Disk Requirements for DB Servers

Please keep in mind that this does not take precedence over the information provided in the MS Infrastucture Planning Guide.

Full documentation and planning guidance for System Center 2012 Service Manager can be found HERE.

Alternatively, the documentation may also be found in Microsoft’s TechNet Library.

The following calculations were derived from the ‘SM2012_Sizer.xlsm‘ (sizing calculator) contained within the SM_job_aids zip file from Microsoft. Though the calculations below may vary slightly from what is in the sizing calculator mentioned above, they should nonetheless be very close.

Please keep in mind that the default settings for data retention of 90 days in the Management DB and 1095 days in the Data Warehouse are the “Best Practice” recommendations from Microsoft. If we choose to set the retention for longer periods of time, we can mitigate performance issues within the console through the use of multiple work item views as well as adding CPU cores/ threads and memory to the server.

With that said, here is the math…

Service Manager DB Sizing

#of computer work items per month

(#of Computers in CMDB * #of new incidents per month) + #of new change requests

  • EXAMPLE:
    • 10,000 Computers * 3 new incidents per month = 30,000 new incidents per month
    • 30,000 + 500 new change requests = 30,500 computer work items per month

SvcMgr DB (GB)

1 + ((500 +( 5 * Work item retention days)) * #of computer work items per month) / 1,000,000

  • EXAMPLE:
    • 5 * 180 Work item data retention days = 900
    • 1 + 500 + 900 = 1,401
    • 1,401 * 30,500 = 42,730,500
    • 42,730,500 / 1,000,000 = 42.7305
    • SvcMgr DB = 43GB

Minimum total disk size (GB) for DB

SvcMgr DB *1.53

  • EXAMPLE:
    • 43GB * 1.53 = 65.79GB
    • Minimum Total Disk = 66GB

Data Warehouse Sizing

DWStagingandConfig

SvcMgr DB Size * 2

  • EXAMPLE:
    • 43GB * 2 = 86GB
    • DWStagingandConfig = 86GB

Repository

SvcMgr DB * (Data Retention Days/365) * 2

  • EXAMPLE:
    • 1095 Data Retention Days / 365 = 3
    • 43GB * 3 = 129GB
    • 129GB * 2 = 258GB
    • Repository = 258GB

DWDataMart

SvcMgr DB * (Data Retention Days/365) * 2

  • EXAMPLE:
    • 1095 Data Retention Days / 365 = 3
    • 43GB * 3 = 129GB
    • 129GB * 2 = 258GB
    • DWDataMart = 258GB

TempDB

SvcMgr DB * 5

  • EXAMPLE:
    • 43GB * 5 = 215GB
    • TempDB = 215GB

DWASDataBase

DWDataMart * 0.2

  • EXAMPLE:
    • 258GB * 0.2 = 51.6GB
    • DWDataMart = 52GB

Minimum total disk size (GB) for DW

(DWStagingandConfig + Repository + DWDataMart + TempDB + DWASDataBase) * 1.53

  • EXAMPLE:
    • 86GB + 258GB + 258GB +215GB + 52GB = 869GB
    • 869GB * 1.53 = 1,329.57GB
    • Minimum Total Disk = 1,330GB