I Love Powershell

Archive for the ‘OneLiner’ Category

Did you move domains recently or reconfigure your System Center Configuration Manager (SCCM)?  Maybe you’ve found your Config Manager site code broken.  Here’s a one-liner that shows you How to update a sitecode for SCCM with PowerShell.

This assumes that you’ve got SCCM running, and installed on the client.  I found this problem hanging around on our machines after a migration from an old domain into the new domain.  Each domain had Microsoft Configuration Manager installed on it, and each domain had a different site code.  A domain wide group policy was used to install the client in each domain, but I had problems with the site code for the old domain still on the Configuration Manager client after domain migration was complete.

Luckily, we can use PowerShell to change the site code, and we can even use PowerShell to discover published site codes. 

First we need to grab hold of our SMS client.  In PowerShell, it couldn’t be easier:

$sms = new-object –comobject “Microsoft.SMS.Client”

We can use the methods of the Microsoft.SMS.Client class by using PowerShell to directly work with the SMS client object:

$sms.SetAssignedSite(“ABC”)

or find out what the site code is currently set to:

$sms.GetAssignedSite()       # This returns a string value

Since the GetAssignedSite() method returns a string, it can be used in scripts to verify the site code is correct.  I use this on scripts (pushed via Group Policy on the domain roots) to verify the site code is correct, and correct the site code automatically if it is wrong.

Since I know the site code, let’s say “ABC” is the new domain and “XYZ” is the old domain, I would use this:

$sms = new-object –comobject “Microsoft.SMS.Client”

if ($sms.GetAssignedSite() –ne “ABC”) { $sms.SetAssignedSite(“ABC”) }

Finally, I’ll call attention to another method of the SMS Client object:  AutoDiscoverSite()

AutoDiscoverSite returns a site code for the Active Directory Domain (if published)

$sms = new-object –comobject “Microsoft.SMS.Client”

if ($sms.GetAssignedSite() –ne $sms.AutoDiscoverSite() ) { $sms.SetAssignedSite($sms.AutoDiscoverSite()) }

Now just a little clean up here…

Write-host “Thanks for reading.  Subscribe! Or, connect via Twitter  or Facebook.  Ask questions to twitter using #poshhelp or #powershell to get q’s answered fast!”

$null = $thisBlogPost

Because of my self-appointed title as an Ultimate Microsoft Fanman, it really pains me to disclose this One-Liner.  That’s because saying it is a commonly used suggests that Internet Explorer locks up frequently.

Ouch!  That hurt to type!

Truthfully, it could have been said of Firefox if I used it as much as I use IE.  And to be fair, Internet Explorer might not lock up as much if I didn’t abuse it by keeping 25 windows open all the time, and continue to upgrade to the most recent beta version I can get my PowerShell-scripting hands on.

So when I get stuck, I dropped this One-Liner out there.  It works great, even if the IE window is not responding to close requests through the taskbar, or through the close button on the application itself.  This kills every Internet Explorer window

get-process iexplore | stop-process

You can exercise more surgical precision by going for only the top processor intensive process (or processes if you change “–First 1” to “-First 2”)

get-process iexplore | sort –descending cpu | select –First 1 | stop-process

Or by going for only the Internet Explorer windows with active threads

get-process iexplore | ? {$_.threads | ? {$_.threadstate –eq “Running”} } | stop-process

I really like this method the most.  The thing that gives it an extra edge over the other methods is that if it kills open tabs but not all the tabs on a window, then the tab is reopened automatically.  Hopefully it’s enough of a kick in the pants to get the window open.

Have I overlooked something?  How can it be done better?