Sccm 2007 Allow Advertisement to Run Again on Computer

Scripts are very commonly used to 'wrap' vendor installation packages and perform additional tasks to attain a comprehensive desired installation issue. For example, script code tin can perform preparation tasks before running the vendor installation, also equally mail-installation tasks. There are hundreds of possible reasons for using scripts to aid with the automation of a deployment through Configuration Manager.

• Author
• Recent Posts

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Procedure Automation.

Along with the added flexibility and control scripting provides, at that place are also added risks. The risks are increased because you (or the script writer) are more likely taking over control of the execution sequence, as well equally taking control over the passing of the final result "code" (i.due east. "exit code") back to the Client agent. The get out lawmaking is what the Configuration Managing director Client reports back to the Direction Signal for aggregate status reporting.

Symptoms ^

1. Reports show "Succeeded" condition for Advertisement even though they failed to run.
2. Reports evidence "Failed" status for Advertisement fifty-fifty though they were successful.
3. Reports bear witness "Failed" along with "runtime exceeded" indicating the installation hung and was aborted when it reached the maximum allowed runtime.
4. Reports bear witness "Running" condition for Advertisement indefinitely

Potential causes ^

1. Script code is passing back an incorrect result lawmaking for the action terminal executed
2. Script code is passing back an explicit value rather than the actual outcome of the action final executed (almost the same every bit the previous cause)
3. Script contains a prompt or a argument that causes information technology to pause during runtime
4. Script launches processes without waiting for them to finish before continuing on
5. Script code logic focuses only zero (0) return values as "successful". Windows Installer render codes such as 3010 and 1605 can also be treated every bit "successful" in some circumstances. (exist careful with using "if exitcode <> 0 so…")
6. Script code neglects handling of concurrent processes which may cause it to become stuck in a property design

Suggestions ^

1. Check that every task or procedure invoked within the script is serialized, rather than asynchronous. If you look the script to wait for an invoked process to stop, make certain the code is doing information technology correctly!
2. If the Advertising is launching a script, verify that the logic is handling exit codes properly. In detail: Windows Installer status codes 3010 (successful, but waiting for a reboot), and 1605 (uninstall did not find the target production to uninstall).
3. If your script needs to run a procedure which expects an existing process to exist terminated (not running), or maybe it expects another procedure to be running earlier it's launched, be sure to handle that. You can start and finish tasks and processes very easily using the TSKILL shell command, as well Sysinternal'due south PSKILL.exe utility. You can too exercise this with script code using COM and WMI interfaces such equally Win32_Process and WSH objects like Wscript.Beat out and Wscript.Network.
4. Bank check the script code for debugging or testing code that should have been removed or commented to suppress it from being executed.
5. If the script is using an iterative statement (loops, do-while, etc.) make sure the logic allows for a "hard out" to break out of the wheel instead of running indefinitely. This is a well-known and very common trouble with programming and has its ain proper noun: "the infinite loop".
6. Check the script code for explicit path references. Sometimes this is necessary, but most of the time information technology'south preferred to apply "relative" path references. If the Package will be replicated over multiple Distribution Point servers, an explicit path reference will finer negate the entire distributed environment and bespeak all of the remote clients back to the explicit path. It will also impact the Distribution Method settings (fast-link, slow-link), specially when a customer meets a condition that results in using "Download and run locally", rather than "Run from Distribution Bespeak".
7. Compare the Advertisement's Distribution settings against the link-speed of the client computer. If the computer is on a "wearisome" link, verify the Advertisement is ready to either "Download Content" or "Do Not Run" rather than "Run from Distribution Point" (for wearisome links).
8. If the script is BAT or CMD shell code, particularly if it uses a "CALL" statement, error codes 255 or 259 might indicate an interactive shell asking. In some cases, setting the Advert to "Allow users to interact with program" tin can resolve this. You may also desire to merge the script code to avert using "Telephone call" to encounter if that helps instead.

Serial vs. asynchronous execution ^

Information technology's possible within a script to launch one process then launch some other without waiting for the outset procedure to complete (asynchronous). If the commencement procedure forces an immediate reboot, it could cease the completion of subsequent processes and may interrupt event reporting (exit lawmaking returned to the Configuration Director Client process).

In general, it's usually preferred to run each process serialized, to allow for evaluating the exit code (result condition) earlier continuing on to the next. In about cases, if one process fails to complete successfully, you wouldn't desire to go along on and launch the next i, at least not without performing some boosted actions commencement.

My examples use VBscript since information technology's relatively more than common with Configuration Manager 2007 packaging than PowerShell. In fact, many SCCM 2007 sites still rely on BAT/CMD scripts. You could do this much more compactly using PowerShell, simply Configuration Managing director 2012 provides a much more robust PowerShell deployment environment than Configuration Manager 2007.

Workarounds ^

If you do not take the luxury of owning a license of AdminStudio or InstallShield, fear not, at that place are workarounds. One such workaround is scripting. You lot can use the COM interface to monitor the Windows Process stack and finer make your script code "wait" until a specific process terminates. This method goes by many names, such as "loop and wait", "watching the clock", or "rock and roll" (I'thousand certain there are many others).

Hither'south an example using VBscript that watches for a procedure named "acme_setup.exe" in the Process stack. If information technology finds it currently running, information technology uses a WMI consequence monitor to wait until it'southward terminated and so moves on:

Const strComputer = "." Const strProcName = "acme_setup.exe"  Dim objWMIService, colItems Dim query, objItem, queryMonitor  Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")  query = "SELECT ProcessId FROM Win32_Process WHERE Name='" & _   strProcName & "'"  Wscript.Echo "info: checking if " & strProcName & " is currently running..."  Set colItems = objWMIService.ExecQuery(query,,48)  For Each objItem in colItems   intProcessID = objItem.ProcessId Next  If intProcessID <> "" And so   Wscript.Echo "info: " & strProcName & " process ID is " & intProcessID   Wscript.Echo "info: waiting for " & strProcName & " (" & _     intProcessID & ") to exist terminated..."    queryMonitor = "SELECT * FROM " & _     "__InstanceDeletionEvent Within 1 " & _     "WHERE TargetInstance ISA 'Win32_Process'"    Gear up colMonitoredProcesses = _     objWMIService.ExecNotificationQuery( queryMonitor )    Do Until processEnded = Truthful     Set objLatestProcess = colMonitoredProcesses.NextEvent     If objLatestProcess.TargetInstance.ProcessID = intProcessID So       processEnded = True     End If   Loop    If processEnded = True So     Wscript.Repeat "info: " & strProcName & " terminated."   Cease If Else   Wscript.Echo "info: " & strProcName & " is not currently running." Terminate If

Some of you lot may exist wondering how you would utilize this in a real globe situation. Let'south say you need to launch a vendor installer and wait for it to consummate before continuing. Maybe you lot'd like to be sure that it actually completed successfully so that your next step is doing something to the results. For example, maybe later on the installation finishes, you need to overwrite some configuration files in the installation target directory, or update a item set of Registry key values. It wouldn't make much sense to endeavor either of those tasks if the installer failed (or never ran at all).

Annotation: The example shown above is not intended for production employ, but but to demonstrate one possible method for monitoring a running process until it terminates before continuing on with script execution. Test thoroughly before using. Use at your ain chance.

The WSH Run() method ^

Scripts that employ the Windows Scripting Host Run() method (Wscript.Shell object), should specify the third parameter every bit Truthful (wait for completion), rather than False (do non wait). Here's a curt VBscript example:

Set objShell = CreateObject("Wscript.Beat out") exitcode = objShell.Run("msiexec.exe /i myInstaller.msi /qn", 7, True)

One of the most common scenarios where I've seen this happen is where the developer decides to use an evaluated variable for the third parameter which is derived from a condition. In cases where the status sets the variable to False (or whatever "non-True" result) it will effectively run the shell process without waiting for it to complete earlier moving on. It's ever best to use an explicit Truthful or False (preferably True).

Command beat out scripts ^

When using the Start control within a BAT or CMD script, be sure to include the /Look parameter, but keep in listen that whatsoever is being launched will control the behavior of the "wait" condition. This ways that using "/Expect" is not a guarantee it will "await" for the unabridged process to terminate. In other words, and this is very common: If you lot launch an installer utility, and it in-turn launches sub-processes, but exits from the call stack while the sub-processes continue running, the START command will only see the offset process (the one it called) as completed, and continue on. The best way to insure this doesn't occur in your script is to follow the 2 rules below:

1. Write log output from inside your script on EVERY step it performs, even before and after each START command is issued. Watch the log file interactively using a live query utility like Trace32.exe or CMtrace.exe.
2. Exam... Test... Test, and Test again!

1 more note of circumspection ^

As with the potential "wait" upshot described to a higher place for Command Shell Scripts, the same may be truthful for the WSH Run() method. That's right. Not because it won't actually "await" for the procedure it launches to terminate its task, simply because that process may in-turn launch other processes asynchronously. In fact, this is non uncommon for processes that create and start Windows Services. The only manner to effectively verify this condition is to monitor the procedure stack in a test environment.

Tools like Sysinternals' Process Explorer, Process Monitor, PSLIST so forth can be of enormous help in identifying and monitoring such branching of processes. The first figure below shows PSLIST in action using the -T option (tree-view brandish). The figure below that shows Process Explorer monitoring a slightly more than complicated process tree.

PSLIST

Procedure Explorer

 In the Process Explorer case above, the installation of a software product is initiated with a .CMD script. The script first checks if Microsoft .NET Framework 4.0 is installed, and so checks if a required update for .NET four.0 is installed. Not having detected the required update, it and then launches the installer (the nested process with name that begins with "NDP40-KB2468871…"), which in-plough extracts a payload of installer binaries, and then launches the installation itself using a "setup.exe" file. The "setup.exe" file in-turn runs a series of Windows Installer packages (the "msiexec.exe" processes highlighted above).

I could have scoured through the vendor's installation logs, and hours and hours of picking out which log acquired which other process to launch then find its log and go along on. Simply seeing the "existent time" processes unfold before me not but saves time, just immediately points me in the right direction.

The indicate of this case is to demonstrate that without the proper tools to diagnose and take hold of this type of scenario, it can be extremely hard to accurately trace what's really going on with an installation sequence. Any nested process can run across a problem that can cause the entire sequence to fail, or worse: partially neglect.

This is why it is absolutely crucial to include every bit much status logging as possible throughout every script. I cannot emphasize that plenty.

My personal recommendation is to impress out a statement of what the next step is going to do, and how information technology volition try to exercise information technology, and then print out the results of that stride if and when it is completed, whether successfully or otherwise.

Every bit I said, script requite yous enormous flexibility and control, but they don't negate the need to perform due diligence.

Helpful links ^

• Troubleshooting Software Distribution Issues
• (MSDN) RUN Method (Windows Script Host)
• (MSDN) Win32_Process Class
• (TechNet) Custom Error Codes for Configuration Manager 2007
• (TechNet) Outset command reference
• Windows XP "Commencement" control reference
• Search the web for "config manager parcel scripting"

chabrillanannothing.blogspot.com

Source: https://4sysops.com/archives/sccm-2007-advertisement-errors-involving-scripts/

Share this post