This displays a hidden web part

Enter a name for your new “Dataset”, here I’m using ComputerModels.xml.

Expand out the Dataset section and add your SQL server name and Configuration Manager database name.

Now add your SQL query. I just want a pie chart of my computer models, so a simple query will suffice:

Select top 10 v_GS_COMPUTER_SYSTEM.Model0 as Model, COUNT(*) AS ‘Count’ FROM v_GS_COMPUTER_SYSTEM
GROUP BY v_GS_COMPUTER_SYSTEM.Model0 ORDER BY Count(*)

Click to Validate your query, then expand out the Chart section

I want a pie chart called Computer Models, fill in the boxes and click Save and Close.

Now all that’s needed is to add the newly created dataset to a web part. Click “Add a Web Part” on the page where you wish to display your lovely new chart.

Select Microsoft Dashboard Viewer from the list of webparts

This will add a blank web part to your site:

Click Edit and select “Modify Shared Web Part”

In the right hand pane, click in the “Select Dataset” box and select the ComputerModels.xml we just created

Apply this change and click the Home link on the top of the page and you’re done!

The task sequence execution engine failed executing the action (Capture User State) in the group (State Capture) with the error code 2147942402
Action output: 0, HRESULT=80070002

If you are seeing this, it’s possibly because you have (again!) forgotten to update your Configuration Manager Client package when you installed SP2. At SP2 the agent should have a ConfigMgr Client Version of 4.00.6487.2000. SP1 is 1000.

Right click your agent package and update distribution points, ConfigMgr will automagically pick up the new client source.

Obviously you’ll also need to upgrade the live client…

We also have a new website at http://www.Orinoko.co.uk I am certain this will be a permanent work in progress, but it is an improvement over our previous one at any rate.

To get your license report do the following:

1. Log into the MVLS Site, Hover over Microsoft License Statement
2. Select view Microsoft License Statement
3. Click the + to bring down the Add Agreements Option and add your agreement and enrolment numbers in the field
4. Click calculate new statement
5. Right click on table under License Summary Tab and select Export to Microsoft Excel

Now open this file in Excel. You need to muck about with it a little bit…

Column A will be blank, delete it.

Format the License Version column (C) as TEXT.

Now Save As Excel 2003 XML format.

Copy this into a folder, shared and accessible to the SMS Provider and the user you’re logged in as.

Right click the Asset Intelligence node and select Import Software Licenses

Note, the Example text is incorrect, you need to provide the name of the xml file too.

Complete the wizard and with a fair wind you will be rewarded with a little tick:

In my opinion (having spent all morning getting an import failure) this should also play a little fanfare sound, but it doesn’t.

Looks like we need a few more Project licenses!

We have to install SP2 for ConfigMgr before we can start our Windows 7 imaging. The customer we’re working on has SP1 deployed, the site was originally upgraded from SMS 2003. Suffice to say that the SQL database is in a bit of a mess.

Problem 1.

The installation bombs out with an error in the C:\ConfigMgrSetup.log:

The login already has an account under a different user name.

This turns out to be an issue where we have a SQL account with the NetBIOS name of the server but a login id of the full domain machine account. E.g. The SQL User Name is “SERVER” but the login ID is DOMAIN\SERVER$.

ConfigMgr attempts to add its computer account account to SQL (which is also DOMAIN\Server$) and gets the above error. Deleting the existing NetBIOS name account isn’t possible as it owns the “SMS Admins” SQL schema.

The solution is to grant another account (NETWORKSERVICE seems to work) the ownership of the SMS Admins schema, remove ownership for the NetBIOS named account, then you can delete it and once the account is re-added as DOMAIN\SERVER$ you can transfer the ownership of the SMS Admins schema back to this account.

This was, however, just the start of the problems.

Problem 2.

Error in Setup log:

Cannot create a row of size 8065 which is greater than the allowable maximum of 8060.

I still haven’t got to the bottom of this one except that compressing the database seems to make it go away… At the same time as we were having these problems, our DB was also growing by around 200MB per hour, there’s some discussion here that this may be related to a post SP2 hotfix, but I have not been able to confirm this.

Problem 3

Our database is corrupt. And unfortunately it’s in quite an important table…

Error in the setup log:

The Database ID 58, Page (1:140044), slot 20 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

Running DBCC Checktable tells us that the data is unrecoverable and that only running DBCC CheckDB with REPAIR_ALLOW_DATA_LOSS is going to fix it. After scrabbling around for a while without joy we ran this and it scrapped around 100 rows from the database. Unfortunately the data is in the CI_ConfigurationItems table. There’s a lot of other tables which depend on this, referential integrity issues await!

Problem 3.

Having “repaired” the database we now essentially have a bunch of orphaned items scattered around the Configuration Manager SQL database. This is a real problem as the SP2 setup routine is going to recreate all of the SQL Foreign Key links and if there’s incompatible data in the linked tables the setup routine will bomb out:

The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "Update_ComplianceStatus_CI_UpdateCIs_FK". The conflict occurred in database "SMS_XXX", table "dbo.CI_UpdateCIs", column ‘CI_ID’.

The table will vary, but essentially what this is telling us is that there are records in the Update_ComplianceStatus table that do not have a corresponding record in the CI_ConfigurationItems table, because they were corrupt and have now been removed.

To identify the offending records I executed the following SQL Query

Select distinct CI_ID
From Update_ComplianceStatus
Where CI_ID not in (select CI_ID from CI_ConfigurationItems)

This results in a few records being returned which represent tens of thousands of status messages, inventory records, whatever… They need to be removed:

Delete from Update_ComplianceStatus where CI_ID = ’9420′
Delete from Update_ComplianceStatus where CI_ID = ’9644′
Delete from Update_ComplianceStatus where CI_ID = ’11666′
Delete from Update_ComplianceStatus where CI_ID = ’25041′
Delete from Update_ComplianceStatus where CI_ID = ’26261′
Delete from Update_ComplianceStatus where CI_ID = ’29627′
Delete from Update_ComplianceStatus where CI_ID = ’31677′
Delete from Update_ComplianceStatus where CI_ID = ’33272′

I created the above statements in Excel using Concatenate to add the text to the ID, I recognise that you can do the whole thing programmatically, but this way you can run them one at a time in the SQL interface:

I like this, as these kind of things make me a little nervous…

Once these tasks are complete I rerun setup and wait for the next failure in the log, then repeat the above. A lot.

It took EIGHT HOURS!!!!! but:

Now I need a pint!

It was also a chance to catch up with Jeff Wettlaufer, a Senior Technical Product Manager in the Microsoft System Center division. Jeff’s always interested on the view from the trenches and was kind enough to interview me and Carl from Orinoko about our recent experiences with Windows 7 and System Center. Whether the interview ever sees the light of day, who knows… we’re not exactly well rehearsed in these things so are mainly tongue-tied for the whole thing, but it really did happen:

Jeff, Carl and John, Cardinal Place, 18th May 2010

When deploying the OS we want to add some roles for clustering, DotNet, Powershell, etc. It turns out that the MDT Add Roles task isn’t particularly aware of Server Core or Hyper-V Server, so the DotNet and PowerShell commands don’t work. This isn’t a big deal, as we can just use DISM commands. So,to install DotNet 2, we execute:

DISM /Online /Enable-Feature /FeatureName:NetFx2-ServerCore

NB This is case sensitive. It is also critical to disable 64-bit file system redirection, if you don’t, the 32-bit Configuration Manager agent will execute DISM from SYSWOW64 and you will receive an error in the Task Sequence status messages “The operating system reported error code 11: An attempt was made to load a program with an incorrect format”

That said, I do like SCCM Client Center from Roger Zander. I personally preferred the look and feel of the old SMS Client Center over the new version, but nonetheless, you can get some great results with the new one.

Anyhow, I digress. As I’ve been mucking about fixing hundreds and hundreds of duplicate GUIDs, I’ve also been monkeying around with PowerShell manipulating clients. I am aware of a number of console extensions that enable you to do this kind of thing to whole collections, but, I’m a command-line guy and I am generally working on customer’s infrastructures so don’t want to be cluttering up the console. Further to this, I now frequently use a sequenced version of the Configuration Manager console which makes adding in extensions a little more complex.

As you’re probably aware, PowerShell makes WMI handling nice and easy. I’m a fan of WMIC (WMIC COMPUTERSYSTEM GET MODEL is my 3rd favourite command line trick) but it isn’t remotable, and won’t run through PSExec    I specifically wanted a few hundred machines to give me a DDR this morning, I was in that kind of mood, so to PowerShell.

Powershell WMI

First thing to do is to create yourself a function. Open the PS console:

Function GenerateDDR
{
$SMSCli = [wmiclass] \\$strComputer\root\ccm:sms_client
$SMSCli.TriggerSchedule("{00000000-0000-0000-0000-000000000003}")
}

You’ll need to press return a couple of times after the last line. Now we can execute:

GenerateDDR MYCOMPUTERNAME

Brilliant. There are a few different trigger actions:

Trigger Actions

Hardware Inventory {00000000-0000-0000-0000-000000000001}

Software Inventory {00000000-0000-0000-0000-000000000002}

Discovery Data Record {00000000-0000-0000-0000-000000000003}

Machine Policy Retrieval & Evaluation {00000000-0000-0000-0000-000000000021}

File Collection {00000000-0000-0000-0000-000000000010}

SW Metering Usage Report {00000000-0000-0000-0000-000000000022}

Windows Installer Source List {00000000-0000-0000-0000-000000000032}

Software Updates Scan {00000000-0000-0000-0000-000000000113}

Software Updates Store {00000000-0000-0000-0000-000000000114}

Software Updates Deployment {00000000-0000-0000-0000-000000000108}

There are also a bunch of other client methods:
EvaluateMachinePolicy, GetAssignedSite, PDPMaintenanceTask, RepairClient, RequestMachinePolicy, ResetGlobalLoggingConfiguration, SetAssignedSite, SetClientProvisioningMode and SetGlobalLoggingConfiguration.

So obviously the above function could be modified easily to a GenerateHW, GenerateSW etc. function just by modifying the last two or three digits of the Trigger type.

Now, using the fantastic file handling available in PS we can remotely run this against loads of machines (as long as they’re powered up and accessible…)

To do this we use the magic FOREACH command:

foreach ($StrComputer in Get-Content D:\ClientFix\test.csv) {GenerateDDR $StrComputer}

The output of this (assuming the machines are powered up) is:

For me, this is a great way of performing bulk live client manipulation. PowerShell is a superb utility, but unless I use it frequently I find I quickly forget the syntax of the commands and have to start from scratch every time. This year I’ve promised myself I’m going to migrate from black screen to blue, time to move on from CMD.EXE.

I had a good bit of help with this work from Greg Ramsey and Don Jones.

Around 50% of the clients show up pretty much immediately, but around 1500 are missing. It eventually turns out that this is because these 1500 machines all had the SMS client duplicated on them in a Ghost image, and now we’ve maintained that ID through the ConfigMgr upgrade.

A bit of a nightmare.

In the past under SMS we would have just deleted the SMSCFG.INI from the Windows folder and restarted the SMS Agent Host service which would have regenerated the GUID, these days the ConfigMgr client certificates don’t much like this, so we have to be a little bit smarter about it. We have our own client installation wrapper, SMSSamurai which we use for the client deployment in the first instance. In a scenario where we know there is going to be difficulty with duplicate GUIDs, we have this wrapper generate a new GUID at install time, but in this instance the duplication was not anticipated.

The main problem now is that the machines need to be powered on to be repaired, so it’s a long slow process. I’ve messed around with trying to script this in Powershell, but there’s no WMI provider for regenerating the GUID, so I’ve fallen back on trusty old Tranguid.exe from the SMS 2003 resource kit and PSexec from Sysinternals.

I’ve created a batch file:

REM Cleaining Up Duplicate GUIDS

REM Firstly we kill off the SMS Agent Host (CCMEXEC) service on the remote machine
TASKKILL /S %1 /IM CCMEXEC.EXE

REM Next we generate a new GUID for the machine
PSEXEC \\%1 -c Tranguid.exe /R

REM Now we start the SMS Agent Service back up
SC \\%1 START CCMEXEC

I save this as DeDupe.bat , then executing dedupe.bat brokenclientmachinename will fix the duplicate GUID.

You can check the fix on the client by checking the ClientIDManagerstartup.log:

The batch file above restarts the SMS Agent Host service once the GUID has been renewed. This will result, a couple of minutes later, in a new heartbeat discovery (DDR) being generated. If you are feeling particularly impatient you can kick off a DDR as soon as the batch file completes.

The final piece of the jigsaw is to run the batch file against all clients. To do this we create a “Non Clients” collection (where Client=NULL)

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,
SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.Client is null

Now use View-  Export list to dump this collection to a NonClients.CSV file.

Finally, logged on as a user with admin rights on all PCs run the following:

for /f “skip=1 delims=,” %L in (NonClients.csv) do Dedupe.bat %L

It is possible to wrap this command in a ping task to check that the machine is powered on before attempting the remote commands which will speed the process up considerably.

Onsite here I’m finding that this is repairing around 200 clients per hour. That’s a little slow, so adding a ping test can improve things a bit.

for /f “skip=1 delims=,” %L in (NonClients.csv) do ping –n 1 %L && Dedupe.bat %L

The double & in this command line allows CMD.exe to process the Dedupe.bat file to execute if the ping command produces an errorcode of 0, which it does if the machine responds.

Opening up the properties of the machine and selecting then deselecting the Num Lock option in the BIOS configuration made this go away.

Very odd.