John Quirk's Blog

I want to add another pie chart to the defaults on the rather lovely Configuration Manager Dashboard. I’ve already installed the product, which is very straightforward, so connect to the dashboard and click Site Actions – Edit Page…

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!

A quick update for anyone who hasn’t already seen enough of me (or Carl). The interview with Jeff Wettlaufer mentioned below is now online on the System Center blog – Nexus One, for your , I dunno, enjoyment.

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.

We are deploying Hyper-V Server to Dell M610 blades using Configuration Manager OSD. Deploying servers, as opposed to workstations, has some different challenges, though much is the same. In particular it’s critical to manage the drivers as tightly as you would with a workstation deployment. We’ve suffered a few BSOD’s from having out of date drivers…

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”

Working with Configuration Manager, I am constantly reminding customers that Configuration Manager is a patient man’s tool. Oftentimes there’s no point in trying to speed the application along, there’s latency built into some of the processes occurring under the Configuration Manager hood and there’s generally not a great deal of point in interfering…

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.

Not an error I’ve come across before, but trying to start up a Configuration Manager VM I’ve not used in a while, Hyper-V Manager stated “The WMI object contained an invalid value in property BIOSNumLock” and that the machine was in in “saved-state-critical”.

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.

Some friends of ours recently had some problems with their ConfigMgr infrastructure and ended up with a system which was booting, but the ConfigMgr console showed an unending list of errors… Reporting didn’t function, the distribution manager log was full of checksum errors, lots of WMI and DCOM errors, it wasn’t looking too promising.

After an hour or so investigation it was obvious that fixing it was going to be more difficult that recovering from backup, so a quick server rebuild and we ran through the following process:

Reinstalling SQL

Step one is to re-add SQL. This was the source of the main gotcha, obviously, it’s pretty important to get the collation order right. If you don’t, what you’ll find immediately you’ve reinstalled and recovered ConfigMgr is that the colleval (and other) logs will fill up with collation match errors. This type of error is a source of unending frustration. I nearly always have the same kind of issue with Package Mapping as the Deployment database the MDT creates has a different collation to the ConfigMgr one.

So, to avoid having to detach databases and reinstall SQL, remember that the default SQL install doesn’t have the correct SQL collation, ConfigMgr requires Latin1_General_CI_AS, the default Latin1_General collation would be Latin1_General_CI_AI. In case this is Klingon to you, the CI and AS bits are related to Case and Accent sensitivity. CI=Case Insensitive and CS=Case Sensitive, same for Accent.

To install SQL with Latin1_General_CI_AS you have to tick the Accent Sensitive button and clear the Case Sensitive button in the SQL collation setup routine.

Reinstalling ConfigMgr

This is pretty straightforward, just reinstall it in the same folder as before.

Recovering ConfigMgr

Again, this is pretty straightforward. I have found that the ConfigMgr Site Repair Wizard (from the Configuration Manager Start Menu folder) can be a little unresponsive when you’re launching it, running it as an admin probably makes a difference, but once it’s launched you’re good to go.

All you now have to do is point it at your recovery wizard at your ConfigMgr backup (you do have a backup right?) and it’ll pull the site back together for you.

A Couple of Minor Gotchas

The first problem we had following the restore was that you need to recreate all of the shares you had previously. Obvious, but an easy one to forget, and one which will break your OS builds.

Also, remember to re-distribute your boot media to the PXE service point. Chances are your other package contents is still where you left it, so this will be ok, but you’ve reinstalled WDS, so will need to repopulate it.

Reinstall the MDT. If you’re using MDT, naturally it’ll need to be reinstalled. The console integration will be put back by the site recovery, but the wizards won’t work until you reinstall the app.

Create and delete some dummy collections, advertisements, packages. Any objects you created between back and site loss will be lost now. To avoid any mix-up in the infrastructure it’s a good idea to create a few collections to take the COLLID autonumber beyond anything you might previously created. The same with packages and adverts. This only takes a couple of minutes and can avoid some headscratching later when machines start installing things they weren’t supposed to.

Expect some inventory resyncs. Any machine which submitted it inventory data in the period between site backup and recovery will, in a week’s time (depending on inventory windows of course) send in updated inventory. ConfigMgr will not like this as it will feel like it’s missed out on some inventory so will request a full resync from the client. These will show up as warnings in the Inventory Dataloader. Don’t worry about these, it’s perfectly normal.

I’ve been struggling with this a little, so thought it prudent to add to the glut of improbably remedies to 16389 which litter the internet.

Here I’m trying to build a Windows Server 2008 R2 server using ConfigMgr. The whole thing looks fine until the Windows Setup routine kicks off whereupon I get this error. Accessing a command prompt on the failed machine gives me access to the logs, interestingly there’s nothing on the C: drive other than the log folder:

Delving into the SMSTSLog folder there are the usual suspects, none of which give me anything unusual, but in the C:\SMSTSLog\WindowsSetupLogs folder there’s a SetupAct.log, this is setup actions (not accounts…) and describes in detail each action carried out during the unattended Windows Server installation. Reading backwards from the end I quickly happen across these lines:

——-
Fallback_Productkey_Validate_Unattend: An error occurred preventing setup from being able to validate the product key;

PublishMessage: Publishing message [The unattend answer file contains an invalid product key. Either remove the invalid key or provide a valid product key in the unattend answer file to proceed with Windows installation.]

This installation is blocked from completing due to compliance failures or invalid input; this is not an internal error.

——

So if you were ever wondering what happens in ConfigMgr if you mix up your Windows Standard product key with your Datacenter edition one, now you know!

I’ve had the various bits and pieces that I outlined in my earlier post for a few weeks and have had some time to play around with it.

I started out booting Hyper-V Server 2008 R2 from the USB sticks, this works brilliantly but caused me a few headaches… The primary problem is that I want to be able to administer the Hyper-V instance from a remote Windows 7 laptop. This proved to be pretty complicated without the two being in a domain. It’s possible to get most of the way clear outside of the domain using WinRM TrustedHosts and a few other little tips and tricks. This eventually allowed me to load Server Manager remotely, but I absolutely could not get Disk Administrator to load from the remote machine and didn’t have much better luck with Hyper-V Administrator either.

After getting tied in knots with this I eventually created a physical DC, added my Hyper-V Server machine (booted from USB) and my Windows 7 laptop to the domain and I could then do all the admin I liked. This is fine, but obviously I don’t want to have to carry around an additional physical DC, so I P-V’d this into Hyper-V (probably not a great idea). All was fine until I shut everything down. I’m now in a situation where my Hyper-V server is joined to a domain which is virtualised upon itself. This leads to some, err, inconsistencies in the stability of the environment.

After a few late nights and plenty of red wine one of our Active Directory consultants took pity on me. We decided the best approach was to scrap the Hyper-V Server approach for the first node and install Server 2008 R2 on the physical laptop, make this a Hyper-V machine, then make it a domain controller in a shiny new domain. This done, it’s been solid as a rock. Obviously in a live infrastructure these issues would never arise and we would always plan to maintain at least one physical DC.

I now have a stable, currently single node, Windows Server 2008 R2 Hyper-V laptop and have virtualised a few machines to provide Virtual Machine Manager and Configuration Manager. Next up is DPM 2010, so more on that shortly.

A last point worth making is that performance is very good. Taking the storage away from the laptop hard disk to a much higher performing iSCSI device makes a massive difference to the performance of the VMs. I have a virtualised Windows 7 machine running Office 2010 very happily within this environment which I just RDP into for email, presentations, etc.

ConfigMgr provides an elegant opportunity to manage the local administrator password using a task sequence, collection variable, a package and a little bit of VBScript.

At the most basic level, we want to be able to manage the password of the local administrator account. We want to be able to set the password to be the same across all machines (security issues aside…). To do this we create a collection variable on the “All Windows Workstation or Professional Systems” ADMINPASSWORD=ourpassword.

This is obfuscated in the console, so can’t be read.

We have a package that just contains a single VBScript:

sNewPassword = Wscript.Arguments(0)

Set oWshNet = CreateObject(“WScript.Network”)

sComputer = oWshNet.ComputerName

sAdminName = GetAdministratorName

On Error Resume Next

Set oUser = GetObject(“WinNT://” & sComputer & “/” & sAdminName & “,user”)

oUser.SetPassword sNewPassword

oUser.SetInfo

On Error Goto 0

Function GetAdministratorName()

Dim sUserSID, oWshNetwork, oUserAccount

Set oWshNetwork = CreateObject(“WScript.Network”)

Set oUserAccounts = GetObject( _

“winmgmts://” & oWshNetwork.ComputerName & “/root/cimv2″) _

.ExecQuery(“Select Name, SID from Win32_UserAccount” _

& ” WHERE Domain = ‘” & oWshNetwork.ComputerName & “‘”)

On Error Resume Next

For Each oUserAccount In oUserAccounts

If Left(oUserAccount.SID, 9) = “S-1-5-21-” And _

Right(oUserAccount.SID, 4) = “-500″ Then

GetAdministratorName = oUserAccount.Name

Exit For

End if

Next

End Function

Our task sequence has a single step to call this script from the package we’ve created. The script takes a single parameter of %ADMINPASSWORD%, read by the task sequencing engine from the collection variable created above.

Obviously, this can be advertised out on a recurring schedule to reset password regularly and the only administrative change required is to replace the collection variable value. It is also easily possible to create different collection variable values for different collections, or even on a per-machine basis if desired, simply set the precedence on the new entry to be higher than the default.