Donnie Taylor at myITforum.com

Prepare for ConfigMgr 2012 with these handy Powershell scripts!

dtaylor — Tue, 22 Mar 2011 18:59:00 GMT

So the time is coming - you need to prepare to ConfigMgr 2012. Sure, the migration tool built into 2012 is an awesome product, but don't you think you should clean up your ConfigMgr 2007 infrastructure before you run down the migration path?

Yes...yes you should.

Here are some scripts we have thrown together for a MMS 2011 presentation, but we thought it would be nice to share them out a bit early.

Word of advice: Change servername and site_123 in the following examples to the appropriate ConfigMgr Primary server and Site code.

Packages missing version or manufacturer fields:

Let's talk about package source. You have hundreds of packages in 2007 - some of which have been there before your packaging standards went in. Perhaps you have packages that don't have a version number assigned to them, or don't have a manufacturer assigned to them....you need a quick way to see those packages.

gwmi -computer servername -namespace root\sms\site_123 -class sms_package | % {if ($_.version -eq "") {$_.packageid}}

This simple one-line command (watch word wrap!!) shows you a list of packages that don't have a version. Need to check manufacturer? Just change the script a slight bit:

gwmi -computer servername -namespace root\sms\site_123 -class sms_package | % {if ($_.manufacturer-eq "") {$_.packageid}}

Simple, huh? Now go hunt down the techs that created those packages and beat them around the head and neck.

Unused Packages:

Wait - why would you want to move packages that aren't even being used? Who would want to do that? This script is a bit longer, but gives you a nice output of packages that aren't used in advertisements, depenedent (run another program first) programs, or Task Sequences:

$adverts = gwmi -computer servername -namespace root\sms\site_123 -class sms_advertisement | select-object packageid
$packages = gwmi -computer servername -namespace root\sms\site_123 -class sms_package |select-object packageid
$references = gwmi -computer servername -namespace root\sms\site_123 -class sms_tasksequencereferencesinfo |select-object referencepackageid
$dependent = gwmi -computer servername -namespace root\sms\site_123 -query "select dependentprogram from sms_program where dependentprogram != ''" | select-object dependentprogram

$packagelist = @()
$adverts|%{$packagelist+=$_.packageid}
$references|%{$packagelist+=$_.referencepackageid}
$dependent|%{$packagelist+=$_.dependentprogram}

Foreach ($package in $packages)
{
    $pkgid = $package.packageid
    if (!($packagelist -contains $pkgid))
        {gwmi -computer servername -namespace root\sms\site_123 -query "select * from sms_package where packageid = '$pkgid'"| select-object packageid,manufacturer, name, version}
}

Great - now you can clean those up or just refuse to migrate them.

Validate Package Source:

So now you have a list of packages that are being used, they should have the right version numbers and other fields filled out - better validate your package source before you do any migrating, or this whole thing will come to a crashing halt!

$packages = gwmi -computer servername -namespace root\sms\site_123 -class sms_package
$packages | %{
    if ($_.pkgsourcepath -ne "")
    {
        if (!(test-path $_.pkgsourcepath)) {$_|select-object manufacturer, name, version, packageid, pkgsourcepath}
    }
}

There is one caveot with this script - if you aren't on the site server when you run this command, and if the package source is local (d:\packagesource) then the packages will show up in the invalid list. Either run it from the primary server, or just understand that anything that shows a local path will need to be checked outside of this script.

Move package source:

Right - you have valid sources, packages with all of the appropriate fields...now what? Well, if you are like us, you will probably be moving that package source to a new server when you stand up your new hierarchy. Here is a simple script that will take your package list, move the source files from your old site, and place them in a new source location that is built around the information in the packages. I.e. \\server\packagesource\manufacturer\packagename\version\<actual source files>.

gwmi -computer servername -namespace root\sms\site_123 -class sms_package | % {$pkgman = $_.manufacturer; $pkgname = $_.name; $pkgversion = $_.version; if (!(test-path c:\pub\temp\$pkgman\$pkgname\$pkgversion)) {mkdir c:\pub\temp\$pkgman\$pkgname\$pkgversion}; robocopy $_.pkgsourcepath d:\newpackagesource\$pkgman\$pkgname\$pkgversion /E /R:100 /NP /NFL /NDL}

Find App Model Candidates:

Ok - So now you have your new source - let's talk about finding App Model candidates for CM2012. Obviously MSI packages are the easiest to place in app model - let's find those real quick:

gwmi -computer servername -namespace root\sms\site_123 -class sms_program | % {$prgname = $_.programname; $pkgid = $_.packageid; $commandline = $_.commandline; if ($commandline.contains("msi")) {gwmi -computer servername -namespace root\sms\site_123 -query "select manufacturer, name,version from sms_package where packageid = '$pkgid'"| select-object manufacturer, name, version}}

Great! A list of packages that will make excellent App Models in CM2012. That will make Microsoft very happy.

List Program Requirements:

One last script around packages - let's find out what the program requirements are on your existing packages. It will be nice to have those documented then moving apps over. Warning! This can take a while to run!

#Modify SiteServer value, and Namespace value for your environment.
$SiteServer = "Servername"
$NameSpace = "root\sms\site_123"

#Get all Advertisements
$adv = gwmi sms_advertisement -computer $SiteServer -namespace $NameSpace
#Create an Array for all objects created...
$allObjs = @()
$adv | foreach {
    $myPackageID = $_.PackageID
    $myProgramName = $_.ProgramName
    $myAdvertName = $_.AdvertisementName
    #grab the program for this advertisement
    $prg = gwmi sms_program -computer $SiteServer -namespace $NameSpace -filter "PackageID='$myPackageID' and Programname='$myProgramName'"
    #see if it's configured to run on "Any Platform"
    if ($prg.ProgramFlags -band 0x08000000) {
        #it is configured to run on "Any Platform" - create a new object, and add it to the array.
        $Obj = New-Object PSObject -Property @{
        AdvertisementName = $myAdvertName
        PackageID = $myPackageID
        ProgramName = $myProgramName
        AnyPlatform = $True
        Platform = $null
        MaxVersion = $null
        MinVersion = $null
        Name = $null
        }
       $allObjs += $obj
    }
    else {
        #have to use a wmi accelerator, because SupportedOperatingSystems is a lazy property
        $prg = [wmi] (gwmi sms_program -computer $SiteServer -namespace $NameSpace -filter "PackageID='$myPackageID' and Programname='$myProgramName'").__Path
        $prg.SupportedOperatingSystems | foreach {
            #create a new object for each supported OS
            $Obj = New-Object PSObject -Property @{
            AdvertisementName = $myAdvertName
            PackageID = $myPackageID
            ProgramName = $myProgramName
            AnyPlatform = $False
            Platform = $_.Platform
            MaxVersion = $_.MaxVersion
            MinVersion = $_.MinVersion
            Name = $_.Name
            }
        $allObjs += $obj
        }

    }
}
#select column order, sort, and display in gridview
$allObjs | select AdvertisementName, PackageID, ProgramName, AnyPlatform, Platform, Name, MinVersion, MaxVersion | Sort-Object AnyPlatform, advertisementname | out-gridview
#export to csv
$allObjs | select AdvertisementName, PackageID, ProgramName, AnyPlatform, Platform, Name, MinVersion, MaxVersion | Sort-Object AnyPlatform, advertisementname | export-csv c:\temp\Platforminfo.csv -notypeinformation

This one is a bit longer - mostly because program requirements flag is a lazy WMI property (YUCK!).

List Disabled Software Metering Rules:

Ok, let's swtich gears. How about we look at something else we don't want to migrate....Disabled Software Metering Rules. I mean, really - they were disabled for a reason, right?

gwmi -computer servername -namespace root\sms\site_123 -class sms_meteredproductrule | % { if ($_.enabled -eq $FALSE) {$_.ProductName}}

Quick, simple, and to the point. You could even through some parentheses around that command and appeand a delete to automatically get rid of them.

Dell Server Deployment Pack for ConfigMgr 1.2 Released

dtaylor — Thu, 25 Feb 2010 14:52:00 GMT

The DSDP 1.2 has been released, bringing support for ConfigMgr SP2!

Download:
http://support.dell.com/support/downloads/download.aspx?c=us&l=en&s=gen&releaseid=R260665&SystemID=PWE_R710&servicetag=&os=WNET&osl=en&deviceid=19942&devlib=0&typecnt=0&vercnt=2&catid=-1&impid=-1&formatcnt=0&libid=36&typeid=-1&dateid=-1&formatid=-1&fileid=382477

dell.com/configmgr

dell.com/systemcenter

delltechcenter.com

Check for open transactions on the ConfigMgr database

dtaylor — Wed, 09 Dec 2009 21:38:00 GMT

Open transactions - transactions that run too long or are hung - can cause havoc on the ConfigMgr database. Notice a backlog of files (DDRs or Mifs)? Slow processing in general? Collections having a problem updating? You might want to give this a quick check.

First, lets find out what the oldest transaction on the ConfigMgr database is. Open SQL Management Studio, and start a new query. Change the focus to your SCCM database,and run this command first:

DBCC OPENTRAN

Did any transactions come back? If so, check their start time and make sure they aren't too long in the past. Anything past a couple of minutes, except for the largest of queries, would be unacceptable. Note the Process ID - we will use that next.

So now we know what the oldest transaction is, but what do we do with this info? Let's see what that transaction is doing. Run this command next:

DBCC INPUTBUFFER(<processid>)

You will see a snippet of the code that the process is running. Does this help track down what the open transaction is? Perhaps a long-running query rule for a collection, or a site maintenance task that is hung. Typically you can get a decent idea what it is by examine the output of Inputbuffer.

Now that you know what is causing the problem, how do you deal with it? Well, if you are sure that you want to stop this transaction, you do it easily with one more command. Use it with caution!

kill <processid>

Note that if is sometimes helpful to do these same steps on the tempdb of the SQL server the ConfigMgr database sits on...especially for long running transactions.

Check how long ConfigMgr Site Maintenance Tasks run

dtaylor — Tue, 08 Dec 2009 20:00:00 GMT

Here is a quick and dirty SQL script that will list the site maintenance tasks and how long they ran last. Run this in SQL Management Studio and target your ConfigMgr database.

select *,
floor(DATEDIFF(ss,laststarttime,lastcompletiontime)/3600) as Hours,
floor(DATEDIFF(ss,laststarttime,lastcompletiontime)/60)- floor(DATEDIFF(ss,laststarttime,lastcompletiontime)/3600)*60 as Minutes,
floor(DATEDIFF(ss,laststarttime,lastcompletiontime))- floor(DATEDIFF(ss,laststarttime,lastcompletiontime)/60)*60 as TotalSeconds
from SQLTaskStatus

Find packages not Nomad enabled via Powershell

dtaylor — Thu, 19 Nov 2009 14:47:00 GMT

Here is a quick little script that will search a site server for all packages (software dist, boot image, TS, Image, etc...) that don't have Nomad enabled on them. The script requires Powershell 2 (comes installed in Win7 and 2008R2 - otherwise get it from here). The grid-view output shows package id, package class (image-package, boot-image, etc..), Mfg, Name, etc...

Replace the Sitecode and SiteServer variables with the appropriate values for your infrastructure. Depending on the number of packages, this script might take a minute or two to run. Watch word-wrap!

cls
$Sitecode = "001"
$SiteServer = "servername"
$completed = @()
(gwmi -Namespace root\sms\site_$sitecode -Class SMS_PackageBaseClass -ComputerName $siteserver | % {
    $obj = New-Object psobject
    $package = $_;$pkgs = [wmi] $_.__Path
    if (($pkgs.AlternateContentProviders|Out-String) -notlike "*nomad*"){
    $obj | add-member NoteProperty Class $package.__Class
    $obj | add-member NoteProperty ID $package.PackageID
    $obj | add-member NoteProperty Name $package.Name
    $obj | add-member NoteProperty Version $package.version
    $obj | add-member NoteProperty Path $package.PkgSourcePath
    write-output $obj;$completed = $completed + $obj}} ) |Out-Null
$completed | where-Object {$_.Class -notlike "*updates*" -and $_.class -notlike "*driver*"} | out-gridview

Dell Win7 Driver Cabs Released!

dtaylor — Wed, 04 Nov 2009 05:34:00 GMT

The Windows 7 Dell driver cabs for currently shipping systems have been released!

They can be downloaded from here directly: http://www.delltechcenter.com/page/Dell+Business+Client+Operating+System+Deployment+-+The+.CAB+Files

They can also be downloaded from ftp://ftp.dell.com/sysman or from http://support.dell.com.

The cabs allow for easy import into ConfigMgr or MDT - simplifying driver management of those Dell systems.

Check them out and let us know what you think!

Big thanks go out to the Dell Product Group as well as Greg, Warren and Chris for putting a lot of work into getting these into production.

Dell Remote Access Controller (DRAC) info in ConfigMgr

dtaylor — Wed, 19 Aug 2009 17:38:00 GMT

New page about getting sample DRAC information into ConfigMgr inventory!

http://www.delltechcenter.com/page/Inventory+DRAC+IP+Information+Using+ConfigMgr

Track System Discoveries per site

dtaylor — Wed, 08 Apr 2009 17:55:00 GMT

This is a handy little SQL statement we managed to whip up while working on a discovery problem. This script will show you a count of Machine based discoveries (not user) per site and per discovery type. Output will look something like this:

Count	Site Code	Discovery Type
1999	001	Heartbeat
200	001	AD_System_Discovery
3000	002	AD_System_Group

Basically it will give you a much better chance of finding run-away discoveries in your infrastructure….discoveries that have been set too low or aren’t set frequently enough. You can also narrow it down to a smaller collection, if you wish. To do so, change the ‘SMS00001’ collection ID.

The @variable is the number of days you want counts for. Setting it to 30, for example, would show you the discovery counts from the last month.

Enjoy!

-----SCRIPT BELOW HERE-----

declare @variable as int

set @variable = '7'

SELECT count(agent.resourceid),fcm.SiteCode,Agent.AgentName
FROM v_AgentDiscoveries Agent
JOIN v_R_System SYS ON Agent.ResourceId = SYS.ResourceID
JOIN v_FullCollectionMembership fcm on SYS.ResourceID=fcm.ResourceID
WHERE @variable >= DateDiff(Day,Agent.AgentTime,GetDate()) and fcm.CollectionID = 'SMS00001'
GROUP BY Agent.AgentName,fcm.SiteCode
ORDER By count (sys.resourceid) desc

-----SCRIPT ABOVE HERE-----

Central Texas Systems Management User Group meeting - March 27th

dtaylor — Thu, 05 Mar 2009 02:36:00 GMT

Mark your calendars! The next CTSMUG meeting will occur at the Microsoft offices in Austin Texas on March 27th. Our special guests this time will be none other than Quest software! Come learn how Quest extends and enhances your System Center infrastructures. The festivities will begin at 9:30am. Registration and agenda to be sent out at a later date.

Microsoft Offices:

Stonebridge Plaza, Building One
9606 N. Mopac Expressway, Suite 200
Austin, TX 78759

VBScript for Computer Association with logging

dtaylor — Thu, 08 Jan 2009 21:05:00 GMT

Here is a quick and dirty vbscript that will generate a computer associate between 2 resourceids, logging information to your systemdrive\ConfigMgrComputerAssociation.log.

To use the script, call it with three arguments - script.vbs <sccmservername> <source-computer-resouceid> <destination-computer-resourceid>

Enjoy!

'******************Code Below Here****************

set colargs = wscript.arguments
strSMSServer = colargs(0)
strSourcePC = colargs(1)
strDestinationPC = colargs(2)

'Set Environment Variables
Set oShell = CreateObject( "WScript.Shell" )
systemdrive=oShell.ExpandEnvironmentStrings("%systemdrive%")
computername = oshell.ExpandEnvironmentStrings("%computername%")

'Create Output Log
stroutputlog = systemdrive & "\ConfigMgrComputerAssociation.log"
if objfso.fileexists(stroutputlog) then
objfso.deletefile(stroutputlog)
end if
Set objFileoutput = objFSO.CreateTextFile(stroutputlog)
log "Output log created."

'log the arguments
log "Argument 1: " & colargs(0)
log "Argument 2: " & colargs(1)
log "Argument 3: " & colargs(2)

'Setup Connection
Set objLoc = CreateObject("WbemScripting.SWbemLocator")
Set objSMS = objLoc.ConnectServer(strSMSServer, "root\sms")
Set Results = objSMS.ExecQuery ( "SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true" )
For Each Loc In Results
     If Loc.ProviderForLocalSite = True Then
           Set objSMS = objLoc.ConnectServer(Loc.Machine, "root\sms\site_" & Loc.SiteCode)
           log "Connection established to " & strsmsserver & "."
     End If
Next

'Create the Computer association
associatecomputer objsms, strSourcePC, strDestinationPC

log "Exiting Main Script Body"
WScript.Quit

Sub AssociateComputer(connection, referenceComputerResourceId, destinationComputerResourceId)
      log "Starting AssociateComputer Subroutine"
      Dim stateMigrationClass
      Dim inParams
      Dim outParams
      log "Connection: " & connection & " SourceID: " & referenceComputerResourceId & " DestinationID : " & destinationComputerResourceId
      ' Get the state migration class.
      Set stateMigrationClass = connection.Get("SMS_StateMigration")
      ' Set up the parameters.
      Set inParams = stateMigrationClass.Methods_("AddAssociation").InParameters.SpawnInstance_
      inParams.SourceClientResourceID = referenceComputerResourceId
      inParams.RestoreClientResourceID = destinationComputerResourceId
      ' Call the method.
      Set outParams = connection.ExecMethod( "SMS_StateMigration", "AddAssociation", inParams)
      log "Exiting Associate Computer Subroutine"
End Sub

SUB Log( message )
    '
    ' Log the given message
    '
    objfileoutput.writeline(message)
END SUB

'******************Code Above Here****************

Transcript from DCCU chat on DellTechCenter (1/6/2009)

dtaylor — Wed, 07 Jan 2009 20:10:00 GMT

http://www.delltechcenter.com/page/01-06-09+DCCU+3.0+%E2%80%93+Dell+Client+Configuration+Utility+3.0

Dennis led the chat - and a good one it was! Everything you wanted to know about the Client Configuration Utility.

List of default Task Sequence Variables

dtaylor — Wed, 07 Jan 2009 18:37:00 GMT

Here is a handy link to the Technet library page that contains all of the default Task Sequence Variables. Bookmark this one to keep it handy!

http://technet.microsoft.com/en-us/library/bb632442.aspx

It has recently gone through an update, so most of the variables are no longer on the same page - but the links are on this page to take you to the specific sections.

Script Skeleton for ConfigMgr with Logging

dtaylor — Mon, 05 Jan 2009 15:57:00 GMT

If you are like me, you want a consistent look to your scripts, verbose yet readable output, and a quick connection to your SCCM server or client. Here is a script framework that I use when developing new code. Simply change the SCCMServer variable, change the output log file name, and put your code after the comment 'Start the bulk of your code here".

Now, whenever you want to write something to the output log, simply preface it with the keyword Log. For example:

Log "This is a sample line in the log file. I can append variable names, such as the SCCMServer variable (" & SCCMSERVER & ") anywhere I want."

********CODE BELOW HERE***********

'Creates an environment for the script to work
Set wshshell = WScript.CreateObject("WScript.Shell")

'Set File System Object
set objFSO = CreateObject("Scripting.FileSystemObject")

'Set Environment Variables
Set oShell = CreateObject( "WScript.Shell" )
systemdrive=oShell.ExpandEnvironmentStrings("%systemdrive%")
computername = oshell.ExpandEnvironmentStrings("%computername%")

'Create Output Log
stroutputlog = systemdrive & "\DefaultScript.log"
if objfso.fileexists(stroutputlog) then
objfso.deletefile(stroutputlog)
end if
Set objFileoutput = objFSO.CreateTextFile(stroutputlog)
log "Output log created."

'Set the SCCM Server
SCCMServer = "<YOURSERVERNAME>"

' Setup a connection to the provider.
Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set swbemServices= swbemLocator.ConnectServer(SCCMServer, "root\sms")
Set providerLoc = swbemServices.InstancesOf("SMS_ProviderLocation")

For Each Location In providerLoc
    If location.ProviderForLocalSite = True Then
        Set swbemServices = swbemLocator.ConnectServer(Location.Machine, "root\sms\site_" + Location.SiteCode)
        siteCode = Location.SiteCode
        log sitecode
        Exit For
    End If
Next

'Start the bulk of your code here
Log "Bulk code execution begins now."

'All Done with the script - time to exit
Log "Exiting Script"
WScript.Quit

SUB Log( message )
    '
    ' Log the given message
    '
    objfileoutput.writeline(message)
END SUB

*********CODE ABOVE HERE*********

Let me know if you have any questions or comments. Enjoy!

Updating Statistics in SQL (and why you need to do it)

dtaylor — Thu, 18 Dec 2008 15:36:00 GMT

SQL server uses statistics to keep track of values in an index, and determine when and how to use that particular index while processing a query. This is a horribly simplified definition (because I barely understand it), but basically it means that statistics are a way for SQL to find the best index to use. By default when you create a database in SQL 2005 (such as the ConfigMgr Database), the Auto Update Statistics option is turned on. You can check it by opening SQL Management Studio, right click on the database, select properties, then select the Options.

Now that you know what they are, it's important to know when to manually kick off an update to the statistics. There are times when the key values in an index will change - especially in the ConfigMgr database. Patch Tuesday, for example - there is a lot of new data flooding the ConfigMgr and WSUS databases as clients scan and report back patch status. After large distributions also change a large amount of data in the indexes (status from distribution and advertisements).

Auto-Update of Statistics will catch these changes, but there will be times when you want your queries to execute at their fastest without waiting for the system task to kick off. There are also times when the system task will take a lower priority to other tasks, effectively keeping your statistics out of date. When you need to update the stats on index manually, use the following command:

UPDATE STATISTICS TABLENAME --replace Tablename with appropriate table

This works great on a single table, but who wants to do that for an entire database? Use the built-in stored procedure to update all statistics on all indexes in your database. Be aware that this can take some time, and if you don't have Async Auto Update Statistics on, could cause queries to time-out while it's running.

/******Code Below Here******/

USE ConfigMgr --change to the name of your database
EXEC sp_updatestats 
/******Code Above Here******/

We use this on a set schedule, every 12 hours, to keep our stats update to date, and avoid any priority problems with the auto-update process. This does have an impact on indexes, so be sure you test accordingly.

If you have any questions or comments, please feel free to contact!

Rebuilding Indexes in ConfigMgr Databases

dtaylor — Wed, 17 Dec 2008 17:30:00 GMT

If you suspect that you have fragmented SQL indexes in your ConfigMgr database (confirm those suspicions here), then what are your options? You could wait for your "Rebuild Indexes" ConfigMgr maintenance task to come around again, or you could just go ahead and rebuild those indexes quickly from SQL Management Studio.

If you want to rebuild all indexes in the ConfigMgr database, which is quite a lengthy and process consuming task, you can run this query. Keep in mind that this is an intensive operation, so it's best to do it off hours. Expect it to take quite a while to complete.

/********************CODE BELOW HERE*************/

USE SCCM --Enter the name of the database you want to reindex

DECLARE @TableName varchar(255)

DECLARE TableCursor CURSOR FOR
SELECT table_name FROM information_schema.tables
WHERE table_type = 'base table'

OPEN TableCursor

FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
DBCC DBREINDEX(@TableName,' ',90)
FETCH NEXT FROM TableCursor INTO @TableName
END

CLOSE TableCursor

DEALLOCATE TableCursor

/********************CODE ABOVE HERE*************/

But what if you just want to rebuild a single index? First, you need to know the name of the index. You can find that out a variety of ways, including just looking directly at the table in SQL Management Studio - there is a sub-folder per table for indexes. You can also check out the instructions at the bottom of this page to find the name of the index (http://myitforum.com/cs2/blogs/dtaylor/archive/2008/12/15/check-sql-index-fragmentation-on-the-configmgr-database.aspx).

Once you have the index name, you can run this quick statement to just rebuild that particular index:

/********************CODE BELOW HERE*************/

DBCC dbReindex('INDEX_NAME_GOES_HERE',' ',90)

/********************CODE ABOVE HERE*************/

BTW, the 90 in both queries is a fill factor. Typically you won't have to change that. A useful tip page can be found here:

http://www.mssqlcity.com/Tips/tipSrvSet.htm