A System Center Essentials 2007 server may raise the following alert:

 

Alert: Root Management Server Unavailable.

Source: sce01.domain.internal

Path: sce01.domain.internal

Last modified by: System

Last modified time: 4/11/2008 1:21:26 PM Alert description: The root management server (Healthservice) has stopped heartbeating soon after 4/11/2008 1:18:48 PM. This adversely affects all availability calculation for the entire management group.

The Operations Manager event log on the SCE server may contain the following event:

 

Event Type:    Warning
Event Source:    OpsMgr SDK Service
Event Category:    None
Event ID:    26330
Date:        4/11/2008
Time:        11:41:48 AM
User:        N/A
Computer:    SCE01
Description:
The sdk service lost database connectivity.
Database name: OperationsManager
Server instance name: sql01
Exception Message: Could not allocate space for object ‘dbo.JobStatus’ in database ‘OperationsManager’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

You can resolve this problem by enabling autogrowth on the SQL database files.  Launch SQL Server Management Studio on the SQL server and open the properties of the OperationsManager database.  Select Files, then take note of the Autogrowth setting.

Enable Autogrowth and set it to 10 percent as shown here:

Restarting the “OpsMgr Health Service” or the server should then resolve the alert condition and allow normal SCE operations to resume.

In this article I will demonstrate how to migrate an existing WSUS 3.0 SP1 server from a local SQL Express instance to a remote SQL Server 2005 Database Services instance.

Firstly be aware of these limitations when deploying WSUS with a remote SQL Server instance.

• You cannot use a server configured as a domain controller for either the front end (FE) or the back end (BE) of the remote SQL pair.
• You cannot use a server running as a Terminal Services server for the front end of the remote SQL pair.
• You cannot use Windows Internal Database for database software on the back-end server.
• Both the front-end and the back-end servers must be joined to an Active Directory domain.

1. Download and install the SQLCmd tool on the WSUS server.

2. Install SQL Server 2005 "Client Tools Only" on the WSUS server so that you have access to the SQL Management Studio console.

3. Stop the IISAdmin and Update Services services in Computer Management.  Note the other services that IISAdmin will stop, usually the World Wide Web service and the HTTP SSL service.

4. Use SQLCmd to detach the SUSDB.

C:\>sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

1> use master
2> alter database SUSDB set single_user with rollback immediate
3> go

Changed database context to 'master'
Nonqualified transactions are being rolled back. Estimated rollback completion
100%
1> sp_detach_db 'SUSDB'
2> go
1> exit

5. Copy the SUSDB.mdf and SUSDB_Log.ldf files from the WSUS server to the remote SQL server.  Place them in the default locations for MDF and LDF files on the SQL server.

6. Attach the SUSDB to the remote SQL server.

7. Grant the WSUS server computer account permissions to the SUSDB on the remote SQL server.

8. Configure the WSUS server to use the remote SQL server for SUSDB by modifying the HKLM\Software\Microsoft\Update Services\Server\Setup\SQLServerName registry key.

9. Start the IISAdmin, World Wide Web Publishing Service, HTTP SSL, and Update Services services.  Or you can just reboot the server.

10. Launch the WSUS administration console to verify the WSUS server is connecting to the database successfully.  If WSUS is not working properly double-check the services in the previous step or try restarting the server.  You can also review the Application event log for WSUS errors.

In this article I will outline how to migrate WSUS 3.0 to a new server using a local SQL Express instance and without downloading all of the updates again.

1. Install WSUS on new server with local express database.

2. During configuration wizard choose "Synchronize from another WSUS server…", enter the name of the existing WSUS instance you are migrating from, and then choose the replica option.

3. Complete the configuration wizard (some options will be skipped due to being a replica server)

4. Wait for initial synchronisation to complete. This will synchronise update files, approvals, and computer groups, but not other server settings. This step saves you having to download your approved updates from the internet again.

5. Change the new server from a replica to standalone.

6. Download the WSUS API Samples and Tools from Microsoft and install it on each of the servers.

7. On the old server open a command prompt and navigate to the C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationExport folder.

8. Run "wsusmigrationexport.exe settings.xml" to export the settings. This will backup your approvals and target groups to an XML file.

9. Copy the XML file to the new server.

10. On the new server open a command prompt and navigate to C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationImport folder. Run "wsusmigrationimport.exe settings.xml All None".

11. Configure your server settings (products and classifications, auto-approvals, email alerts, etc) on the new server to match the old server.

12. Update your GPOs to direct clients to the new WSUS server.  If you are using GPOs to assign computers to Computer Groups in WSUS then no further action is required.  If you are manually assigning computers to Computer Groups in WSUS then all clients will initially end up in Unassigned Computers when they report in to the new WSUS server and need to be manually assigned to their correct group.

I was doing a little cleanup of the C: drive on a server that was unfortunately created with too small a volume size.  One of the things I deleted was all of the files and subfolders in the Temp folder of my user profile.  A few minutes later I launched the System Center Essentials 2007 console and was greeted with this error.

 

Could not find a part of the path “C:\Documents and Settings\username\Local Settings\Temp\2\0_u8ex1o.tmp”.

The fix was simple enough - create the “2″ folder again and then relaunch the console.  Here is the stupid part - the “2″ folder doesn’t exist in the Default User profile on this server.  So presumably the first time the SCE console is run it is able to create that folder itself as required.  I guess after that it forgets how to do it.