Article: A Deep Dive into Active Setup: Part 3
by Jacob Kimbrough
Jacob Kimbrough is a Consulting Architect at Fulcrum Technology Solutions. Kimbrough joined the Infrastructure team in 2014.
In Part 1 of this series, we looked at what Active Setup is and some use cases that I solved using Active Setup. Next, in Part 2, we looked at the technical side and inner workings of an Active Setup component along with some testing methods. In this part, we will take a look at some very important “gotchas” and workarounds for each one.
Gotchas! Really, Take These Into Account
Here is what I really want to get at. I have been bitten by ALL of these at some time. The documentation is pretty poor, so you don’t always know why your Active Setup component is failing.
There is no timeout mechanism!
If you run a script that prompts the user, but doesn’t display that prompt (as an example), the component will hang forever and prevent user login. Any user login, including the Administrator! You’d have to remote-edit the registry to correct the situation (or employ some other hack/recovery mechanism). You can easily “hang” explorer.exe and, from the user’s perspective, keep it from loading.
Do you need a long-running process to execute?
No problem; spawn off your process. There is a rather awkward construction that will allow this. Let’s assume you want to run a PowerShell script called “MyScript.ps1”. Your StubPath would look like this:
cmd.exe /c “START “My script” powershell.exe -File “C:\Program Files\Scripts\MyScript.ps1″”
What are we doing here?
|cmd.exe /c||Launch a separate cmd.exe session. “/c” means run the process and then exit. What are we launching?|
|“START …”||A START command. This is what will spawn off our PowerShell executable.
It is in quotes because we’re telling cmd.exe to run everything in the quotes. That includes START.
|“My script”||This is a parameter of START that is required: the window title|
|powershell.exe||The executable we are running. It happens to be a script interpreter.|
|-File “…\MyScript.ps1”||The name of the script. Just a parameter to powershell.exe.|
What’s going on with the quotes?
cmd.exe is executing everything in the outer quotes. Quotes inside that parameter are fair game. Strange? Yes! Be sure to put the fully-qualified path to your script inside quotes as well if any spaces are in that path.
Hide the window from the user?
Fine, but you should also include “-NonInteractive” to ensure no user prompts:
cmd.exe /c “START “My script” powershell.exe -WindowStyle Hidden -NonInteractive -File “C:\Program Files\Scripts\MyScript.ps1″”
Seeing how these command lines can get long, you see why I ran into the next Gotcha:
StubPath can not be more than 255 characters or it will fail and give no explanation as to why!
That’s right. If you use a long StubPath (and with long paths and character escapes, this is easier to do than you might think), your component will appear as though it has simply not executed. If your StubPath is 255 characters exactly, it will run; if it is 256 characters or more, it will not execute. HOWEVER, it WILL mark the user part of the registry as executed. Be warned!
What can you do if you really need a long command? In the past, I’ve created a batch script for the long path and used Active Setup to execute the script.
StubPath does not look in the System or User path environment variable.
The StubPath command must be fully qualified path and quoted if there are spaces. Backslashes and quotes must be escaped. It will look in the Windows directory and Windows\system32 directory; for example, for cmd.exe or powershell.exe.
Version should be a number (or comma-delimited version string).
If you use a letter for Version – let’s say you used “a” – then sure, your Active Setup component will run. Once. If you examine the USER portion of Active Setup, for a user who has already executed your component, you’ll see that no Version is recorded.
For grins, let’s say that you now increment your Version string in the system part to “b”. What happens when your user logs back in? Nothing! Your component has already been run! Active Setup will not evaluate non-numeric characters for the purposes of Version control.
What’s more: if you change tactics – for example, you were using straight versions (1/2/3/etc), and now you want to use a version “string” (1,0/1,1/1,2/2,0/etc). In this case, Version will not evaluate properly and your Active Setup component will never run again for your users. You would, in this case, have to create an entirely new component.
Published Application scenarios will not work with Active Setup without some trickery. (Assuming we’re talking about Citrix or RDS servers here, not Windows desktops… although you could have Kiosk use cases). Why? Because if any shell other than explorer.exe is run, Active Setup is not run. This would be the case for a Citrix published application, or, an RDP session where a particular application is the only executable launched at logon. (RemoteApp is good example of this). However, there is a solution:
Run this as part of a logon script for your server or kiosk (or place in the Run or RunOnce keys):
Active Setup components run as the user.
That means the user may not have local Administrator permission. Keep that in mind when designing a solution.
If you run PowerShell scripts, you must either sign them with a valid cert or run powershell.exe with the “-ExecutionPolicy Bypass” option.
This isn’t Active Setup advice but rather advice for life in general: if you have a default script policy set up and don’t sign your script and don’t tell PowerShell to bypass the policy, then your script won’t run.
That’s it for Part 3. In the final part of this series, I will discuss a special case of using Active Setup in an RDS RemoteApp or Citrix published app situation. I’ll also present some bonus material for ordering Active Setup component execution and give you a PowerShell function that you can run as SYSTEM (or from SCCM) to create an Active Setup component easily on a target system.
The Fulcrum Difference
At Fulcrum Technology Solutions, we differentiate ourselves from other technology- and business-consulting firms with a unique guarantee: when you hire Fulcrum, we commit to finish the job. Whether working under a time-and-materials contract or a cost-plus arrangement, we will not leave until we’ve delivered exactly what we said we’d do. Our word defines us, and motivates us to give you the service that you deserve!