Monday, January 19, 2009

Unable to import AI license file

So our software licensing team asked about using SCCM's Asset Intelligence to track software license usage at our company. After going through all of our normal internal testing we were ready to import our xml formated license file into our site. However when we tried to import it on our production server we received a single message:


Unable to connect to the site database

Not very useful since my console and site server were obviously talking to the site database just fine. I spent many hours troubleshooting this one myself before calling Premier support. At which time I spent many more hours troubleshooting on the phone with them and fearing that the issue would be unresolved. We went through all kinds of troubleshooting of both my SQL server setup and my site server setup.

The only error message with any meaning behind it was when we tried to run the import manually:

D:\SMSPROV\bin\i386>mvlsimport.exe /file //server/share/MSLtest.xml

Failed to get Site Database configuration information.Failed to get Site Database connection.Failed to intialize.

Yes, those are forward slashes, per explicit instructions by Microsoft Support.

My gut told me it was a bug in SCCM, but how my site differed eluded both me and Microsoft support. Ultimately, by sheer luck a stumbled across the steps that would enable me to reproduce the bug on my own. My site had an unrelated hardware failure and I had to rebuild and recover it. As I rebuilt it I tried the import several times along the way, until it finally failed. Once I was able to reproduce the bug I let Microsoft know how my site differed from a working site. Turns out there is a bug importing the license file if the smsprovider is installed on another computer other than the site server. Support was then finally able to confirm that this was a bug that they could reproduce and would notify the development team. In the absence of an actual fix, they provided me with a workaround. The workaround is to export the sql node of the sms registry key from the site server and import it onto the smsprovider computer. If you are switching architecture you will have to update the key to compensate for wow6432node as well.

Export this key from your 32-bit site server: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\SQL Server]

Import this key into your 32-bit smsprovider computer.

Or, if your provider is 64-bit, find and replace \software\Microsoft\ with \software\wow6432node\Microsoft

Key will now be in this format:


Now import the new key onto your 64-bit smsprovider computer.

Thursday, January 15, 2009

wsutil to change your wsus server's ports

Following up on my recovery of a sccm site.  My original recovery doc did not specify that during the wsus install, wsus needs to be setup to use its own custom website on ports 8530 (for http) and 8531 (for https).  I later found that if you miss this step  (When you notice your site fails to sync with its wsus database) then there is a simple utility installed with wsus that will allow you to change it.  From the command line:

wsusutil.exe usecustomwebsite true

Also, if your site just isn't syncing for no apparent reason, I've found that a wsus reset may help:

wsusutil.exe reset

You can find wsutil on the wsus server in the program files\Update Services\Tools folder.

Monday, January 12, 2009

Chrome on Windows 7 64-Bit Beta (7000)

This weekend I installed the current windows 7 64-bit beta (build 7000).  All my favorite apps installed just fine including the SCCM console.  I even managed to find a beta build of the rsat tools:  The only thing that I spent a significant amount of work getting to run was google chrome.  I'm still in love with it, and just started using the 2.0 dev beta.  So of course I want to run it on top of my windows 7 beta.  Well now you can.  In the target part of your shortcut to chrome.exe add -in-process-plugins.  It runs just fine now.  Credit to: BlogsDNA

Oh by the way, windows 7 boots faster on the same machine I was previously running vista 64!

Friday, January 9, 2009

Recovery of SCCM Site Failure

Despite the fact that Microsoft has recovery information posted in their online support docs (, site recovery is still a confusing task.  I've gone through several site recoveries and here are the notes from my last one, where the central site happened to fail.  An important note that I don't think is explained very well is that you have to have a functioning site setup the same way as the old site before you can recover the old site.

So before starting the site recovery review the original site setup procedure.  If you don't have one documented, then see the excellent write up by Ying Li:

Notes from recovery of Central site on 12/17/08.

1. OS, Server name, Site Code, and Drive layout (OS on C: and program files on drive d: ) should match original hardware.  (Do not move from 64-bit to 32-bit OS).

2. Install the OS and configure as normal

3. Give the machine account admin rights on the SQL server

4. Install WSUS 3.0 with SP1.  Do not use the default website.  Use custom website.  During install point it to the remote SQL server (if you use a remote sql server to host wsus metadata).  Do not overwrite the contents of the database.  Do not use the configuration wizard to setup wsus.  Simply exit when the configuration wizard starts.

5. Start copying the backup files to the local machine since it can take 1/2 hour.

6. Install the correct version of SCCM

a. Make sure to reuse the same program path (d:\sms for our Primary sites since they were upgrades from sms.  d:\sccm for our Secondary sites, since they were fresh installs when we set them up).  This part is critical.  When you do the recovery step, your site will to use the original setup paths that were in use prior to the site failure.  Changing the paths will cause a significant headache!

b. On a new fully patched system you will not pass the prereq check.  Double click on each item to see how to resolve the issue.  You should be able to resolve every error.

c. After resolving the MMC sp3 issue, it will still show up as an warning in prereq check, that is fine if you are sure you have applied sp3 for MMC.  The setup routine does not correctly query the registry to see that lastest version of the hotfix that Microsoft issued.

d. You can ignore the warning about SQL server authentication mode if you typically run SQL under the system account (without hardening SQL).

e. If you are attempting to restore a site that has a remote provider and point it back to the correct remote provider machine, the installer will complain that machine already has a provider.

1. On the provider machine, the registry key is blocking the install of the new remote provider, so remove the HKLM\SOFTWARE\Microsoft\SMS\Providers key.

2. On the provider machine, connect to root\sms with WBEMTEST and press the 'Enum Classes button'. No input is necessary, just press 'OK' to do an 'Immediate only' search. In the Query Results dialog window, click on the 'SMS_ProviderLocation' and press the 'Delete' key. Close out of all of these dialogs.

3. Delete the SMSPROV folder on the root.

4. Add the new site server machine as a local administrator and remove the old site server (if applicable).

Note: Provider fix, pasted from

f. All other site servers will install the provider on themselves.

g. On the SQL DB server detach the old DB.  Create a new DB with the same name and file locations.  Give the smssite server db_owner on the db.

7. After the install has completed successfully run the site recovery wizard.

a. Close the console if open

b. Start>all programs>Microsoft System Center>Config Mgr 2007>Config Mgr Site Repair Wizard

c. Redsite and ROSsite do not have local DP's installed.  Choose the option to skip package verification.

8. Reset permissions for site in AD.

a. Open AD users and Computers> System> System Management

b. Open properties and give site server full control on Systems Management container.

c. Open advance properties and change permissions so that they apply to "This object and all descendant objects"  (this is not the default so be sure to do it).

9. Restore the site control file

a. Copy  site_control_files sitectrl_<SiteCode>.ct0 to D:\sms\inboxes\

b. Rename file from sitectrl_<SiteCode>.ct0 to sitectrl.ct0

10. After recovery perform a site reset

a. Rerun setup from Start>all programs>Microsoft System Center>Config Mgr 2007>

b. Choose site reset

11. Set user group permissions for recovered site and related site servers

a. Computer mgmt>local users and groups>Groups

b. Sms_sitetositeconnection_<sitecode>  should contain the parent server and any child servers that need to connect to the site.

c. Sms_siteSystemtoSiteServer_<sitecode> should contain any parent or child site that needs to write to the site's DB.

d. Sms Reporting Users should contain any domain accounts that have reporting rights.

e. Sms admins should contain your sms administrators domain accounts.

12. If this was the central site with the wsus updates, then the wsus updates folders need to be reshared with the same share names.  Check the software updates deployment packages nodes.  On each package open the package properties.  The general tab will show the share name that the packages is expected to be found on.  The central site's machine account will need full control of this share.

13. Reset the wsus db:

a. From the cmd prompt:  c:\program files\Update Services\tools\wsusutil.exe reset

b. Wait 1 hour

c. Force a Synchronization on the Update Repository

d. Verify wsus is syncing properly: wsyncmgr.log for errors.

14. Verify backup share permissions for newly restored site.  Our backups are set for a share on another server, which is then backed up to tape.  This can be verified in the site maintenance node and by reviewing the smsbkup.log located in the backup share.

15. If this was the central site, recreate the backup schedule for the site control file.  A scheduled task that runs every 15 mins to dump the site control file and copy them to another machine:

a. site_control_file_backup.bat

D:\sms\bin\i386\00000409\preinst.exe /Dump

xcopy d:\*.ct0 backup_location\site_control_files /C /Y

16. Check and review system logs for errors for the next several days.

17. Monitor Site Status for errors.  The only errors should be on the central site and be related to unapproved clients trying to get policy.  Recheck in 24 hours.

18. Verify successful backups by reviewing the smsbkup.log located in the backup share.