This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 93%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
I have a PowerShell script that deploys a package at the end of a task sequence, after several reboots. The application is a wix burn based installer and requires much custom manual work to deploy. It is also extremely resource-intensive during the deployment stage.
The virtual machine is adequately provisioned, and the host is as well. The application runs well post-deploy when installed from a regular session.
However, I am unable to install it from within the ts environment, based on logging and behavior, it simply appears to be a resource contention issue.
I am aware of the limits of the pe environment, however, I am unable to find any documentation that discusses any limits imposed by the setup environment.
Does anyone know if this is the case, and if so, whether a workaround exists?
Thanks.
If you're installing the Application near the end of the Task Sequence, and you've had reboots since the "Setup Windows and ConfigMgr Client" Step, then you're already in the full OS, not a setup environment.
Have you tested on a more powerful machine to rule out a hardware resource issue?
Can you install the application using a Task Sequence, after OSD?
Hi, you are correct, I am actually not in the OSD stage. The os has been installed and configured, the ConfigMgr client has been installed and a reboot has occurred since.
The vm has 6 cores, 6Gb ram and it is backed by a SAS based r10 array. It is fairly well provisioned. If I log in using rdp, the same script works fine and although the installation process is resource-intensive, it does complete without any error.
This is not a critical requirement, for the few that need this, I can perform this step manually if I must. I would have liked to understand this issue, this is unfortunate.
So when you say that you're running the script manually, you're not running it via Configuration Manager? You're just launching elevated PowerShell and running it? Or are you running it through software center to make sure it's running as System.
Hi, sorry about that, I am logging into the VM through rdp and copying the package data locally from Config Manager, then starting an elevated PowerShell console and finally running the script myself.
Using this approach, the installation proceeds through as expected and reliably.
Do you have the install working from CM at all? If you create a CM Application, does that work when trying to install from software center?
I've seen some issues where some Application Packages from a vendor will just not install properly when trying to install via System Context.
Here's how I would troubleshoot:
Hi Gary,
Without alternate credentials, the PowerShell script runs, but does have trouble completing all the actions in the burn wrapper. When I omit the step from the task sequence and log on through RDP, then launch PowerShell as System, it produces the same effect. It appears your assumption was correct, and this installer does have problems with running as System.
However, when I specify alternate credentials using either the local (.\Administrator) or domain administrator (I am in a small test lab), I get a permission denied exception for both when the script invokes Get-CimInstance Win32_OperatingSystem?
In summary, using nt authority\system in either the task sequence or post install using psexec is not compatible with the installer. However, the PowerShell script only has access to either the cmdlet or the CIM instance (I am not clear which is the result of the error) when not run as System?
Any idea what the PowerShell nuance is here?