ConfigMgr and SQL – NTFS allocation unit size

No Gravatar

It’s been many years since I read that SQL databases should use an NTFS volume formatted with at 64KB file allocation unit size (block size). So long that I didn’t remember why or if it is still considered best/good practice. It appears that it is according to Microsoft and the foremost authority on SQL with ConfigMgr.

keep reading at http://blogs.catapultsystems.com/chsimmons/archive/2016/12/23/configmgr-and-sql-ntfs-allocation-unit-size

December 23, 2016

Posted In: ConfigMgr 2012, Scripting, T-SQL

ConfigMgr Content Source Path migration

No Gravatar

Several ConfigMgr scenarios require that the content Source Path be changed.  This typically includes migrating to a new ConfigMgr environment (2007 to 2012, 2012 to Current Branch, etc.), and simply moving the source content to a new location such as a DFS Share or low-speed NAS device.

Updating the Source Path can be done manually via the ConfigMgr console.  For Packages, Software Update Deployment Packages, Drivers, Driver Packages, Operating System Images, Operating System Upgrade Packages, Boot Images, and Virtual Hard Disks, just add the Pkg Source Path or Package Source Path column to the console view to review the paths, then edit the object’s Source Folder in the Data Source tab.

However, for Applications, you’ll have to step through each Deployment Type on each Application, view the properties and modify the Content Location in the Content tab.

This is all painfully slow if you have more then a handful to deal with.  So, automate it!

image image

The community has developed at least 5 solutions to this including

CoreTech and Nickalaj have the slickest solutions.  Sometimes a GUI gives the visual feedback you need to be confident in the final outcome.

158_1 image

Either of these two tools should effectively handle the changes.  As a bonus, both will actually copy the content files from the old to the new path.  Awesome!

Happy migrating!

September 28, 2016

Posted In: ConfigMgr 2012, Scripting

Tags:

Automating “Click Continue”

No Gravatar

A friend of mine mentioned that he unexpectantly spent a few hours with glazed over eyes clicking “C” on the keyboard to press “Continue” on a dialog box that was being generated a few hundred times.  He quickly acknowledged that there was definitely a better way to use his time and accomplish the task at hand with some bit of code that would prevent the need for clicking a dialog box button over and over, but sometimes we just end up in that frustrating place where that’s just what has to be done.

I immediately thought of AutoIt (http://AutoItScript.com) which is an awesome scripting language that Jonathan Bennett developed many years ago and continues to improve.  AutoIt can do many things easily and well, but one place it excels at is GUI management.  PowerShell, VBScript, KiXtart, and others can certainly send key presses, but AutoIt can do much better.  It can programmatically “click” buttons by name or control ID.  The greatness of this is that the dialog box doesn’t need to be “active” or even visible.  I’ve used this process hundreds of times in a former role to drive software installations where MSI’s didn’t exist and repackaging was unacceptable.

 

Here is a code snippet that will indefinitely watch for a dialog box and click the first button.

$DialogTitle = “Error Applying Attributes”
$IdentifyingText = “Access is denied.”
While 1 ;run forever
If WinWait($DialogTitle, $IdentifyingText, 5) <> 0 Then ;wait up to 30 seconds for the dialog box with the title and text to exist
ControlClick($DialogTitle, $IdentifyingText, “[CLASS:Button; INSTANCE:1]”) ;click the first button
EndIf
WEnd

 

You’ll need just two files from the AutoIt download: Au3Info.exe and AutoIt3.exe

Run Au3Info.exe, unfreeze the windows (Menu | Options | Freeze  OR  Ctrl+Alt+F), bring the dialog box you want to manipulate to the foreground, then freeze Au3Info.

image

 

Update the DialogTitle and IdentifyingText variables and the Button Instance number.

Lastly, run the AU3 script using the AutoIt3.exe (drag the script onto the executable or run it from the command line) and watch the dialog boxes popup and get answered to your heart’s content.

 

By the way, check out Jonathan’s other work including GImageX which allows GUI modification of ImageX (WIM) files.

October 15, 2014

Posted In: Scripting

Change SCCM 2012 Site Name/Description

No Gravatar

Changing the site name or description in SCCM is frankly a pain in the rear.  To my knowledge SCCM doesn’t use it internally and it is simply a description for the administrators to identify some characteristics about the site.  This is really only needed because the Site Code is limited to 3 characters… still.  </end rant>

I have a System Center 2012 Configuration Manager Secondary Site server and need to change it’s name/description.  In SCCM 2007 this could be done by editing the Site Control File which is unsupported by Microsoft.  SCCM 2012 doesn’t use the same type of Site Control file, it is an XML embedded in SQL.

Rikard Rönnkvist has a simple SQL statement for changing the Site name/description here: http://www.snowland.se/2012/10/12/update-configmgr-site-description

Anoop C. Nair does some interesting investigation with the embedded Site Control file here: http://anoopcnair.com/2012/05/23/configmgr-sccm-2012-how-to-edit-site-control-sitectrl-file

But I really didn’t want to hack the database.  I went looking for a WMI method and found Peter van der Woude’s PowerShell script to change a Primary Site name/description here: http://www.petervanderwoude.nl/post/changing-a-site-name-in-configmgr-2012-via-powershell

I’m still pretty new to PowerShell, but after poking at it a bit I was able to modify it to change the name/description of a Secondary Site.  Here’s the end result.  95% of the credit goes to Peter.  Thanks, Peter!

Save this code as a ChangeSiteName_v1.1_ps1

[cc lang=’powershell’ ]

[CmdletBinding()]

param (
[string]$PrimarySiteCode,
[string]$PrimarySiteServer,
[string]$SiteCodeOfSiteToChange,
[string]$NewSiteName
)

function Change-SiteName {
$Site = Get-WmiObject -Class SMS_SCI_SiteDefinition -Namespace root/SMS/site_$($PrimarySiteCode) -ComputerName $PrimarySiteServer| Where-Object -FilterScript {$_.SiteCode -eq $SiteCodeOfSiteToChange}
$Site.SiteName = $NewSiteName
$Site.Put()
}

Change-SiteName

[/cc]

Now run it.  It should work remotely, but I ran it from the Primary Site Server.

[cc lang=’powershell’ line_numbers=’false’]

PowerShell.exe -Execution Policy ByPass .\ChangeSiteName_v1.1_ps1 -PrimarySiteCode “PrimarySiteCode>” -PrimarySiteServer “PrimarySiteServer” -SiteCodeOfSiteToChange “MySiteCode” -NewSiteName “MyNewSiteName”

[/cc]

 

September 13, 2013

Posted In: ConfigMgr 2012, Scripting