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
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.
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.
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.
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!