Install TeamViewer during "oobeSystem" (pass 7) WDS
-
I have a working Windows10 image that deploys great using Windows Deployment Services (WDS).
This is a "special" image that is used on special computers that do not join the local domain.
These computers require TeamViewer. We can't have TeamViewer installed as part of the image, so this needs to be installed after the image has been deployed to a computer.
As part of the ImageUnattend.xml attached to the "special image", you would do this via a command or script:
<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <FirstLogonCommands> <SynchronousCommand wcm:action="add"> <Description>Installs TeamViewer at first boot.</Description> <Order>1</Order> <RequiresUserInput>false</RequiresUserInput> <CommandLine>PowerShell.exe -ExecutionPolicy ByPass -File \\server\share$\WDS\FTdeploySoftware.ps1</CommandLine> </SynchronousCommand> </FirstLogonCommands> </component> </settings> </unattend>The contents of "FTdeploySoftware.ps1" are:
Start-Process -NoNewWindow msiexec -argument "/i \\server\share$\WDS\TV11FThost\TeamViewer_Host-idcqsmsmbk.msi /quiet" -WaitThe commands and script contents work great when ran from an elevated powershell or command prompt. But if I run the "CommandLine" part from the .xml in a "Run" box, it does not work. It needs to be ran from an elevated prompt. I verified this by looking at the event logs, and it says the TeamViewer 11 Host msi failed because it requires admin rights (elevation). The "(elevation)" part is my own words.
So now to my question:
How can I get this .msi to install automatically after the image is deployed?
One idea I had was to see if I can disable UAC before I sysprep the image, and see if that survives. Then after deployment, like in the above .xml, run another script turning UAC back on after the .msi and/or other software has been installed.
I haven't tried this yet, but I'm looking for any other ideas before I take the time to try that.
-
Is it critical that it install automatically?
Have you considered using PDQ Deploy (even the free version) supports MSI's.
-
@DustinB3403 said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
Is it critical that it install automatically?
Have you considered using PDQ Deploy (even the free version) supports MSI's.
Yes but the idea is to have this fully automated as part of the imaging process, or followed by the imaging process without any user interaction required.
Normally I'd do this with Group Policy, but as these are off-domain, I can't do that.
-
With the powershell you have, you could modify it so it runs the command prompt as an admin.
start-process powershell -verb runAsAnd then pipe in your installation
-
@DustinB3403 said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
With the powershell you have, you could modify it so it runs the command prompt as an admin.
start-process powershell -verb runAsAnd then pipe in your installation
But won't that throw up a UAC yes/no prompt or require user input? I don't think this stuff runs when the desktop is shown.
-
Not if you provide credentials
-
Your image has a admin user built in, right? Pipe those credentials in and it'll work.
-
@DustinB3403 said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
Your image has a admin user built in, right?
Yes but with a blank password.
Pipe those credentials in and it'll work.
I haven't done that before. Do know off the top of your head how I would set that up for example?
It doesn't matter at this point if this local username/password is in clear-text anywhere.
-
Something like this would probably work.
runas /savecred /user:administrator "\\path\to\executable.msi" -
Using a command prompt for this is kind of backwards though, use powershell.
-
It's one thing to install TeamViewer but another to register with your TeamViewer account and enable unattended access, enforce policy, etc. I thought even if you downloaded the custom MSI you still had to make an API call back to TeamViewer to register the device with your TeamViewer account.
-
Try this within powershell.
runas /user:<administrator username here> "msiexec /i <Path and Filename of MSI" /qn -
@NetworkNerd correct, deploying is easy is the actual activation that requires either a manual step or as you note.
-
@DustinB3403 said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
Try this within powershell.
runas /user:<administrator username here> "msiexec /i <Path and Filename of MSI" /qnLooks like /qn needs to be within the quotes. Changed that:
It will not run in a non-elevated powershell.
Ran the above command in non-elevated powershell:
Three things... 1) it asks for a password 2) Error says 1327: Account restrictions are preventing this user from signing in, 3) if I want to set the execution policy to bypass, it's a no go. -
@Eltolargo said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
@NetworkNerd correct, deploying is easy is the actual activation that requires either a manual step or as you note.
How is deploying TeamViewer during the image deployment process with WDS easy when it simply (seemingly) cannot be done automatically?
I've tried everything. I'm open to more ideas if you've got them!
What it comes down to, is that somewhere in the deployment process, there needs to be a way to run a .msi via an elevated CLI. I just don't think it's possible so I'm about to move on.
I'm thinking the whole method is flawed. Even if I would be able to find a way to get the .msi to run, it doesn't seem like the .xml command will even start the process.
This basically what I'm trying to accomplish, but with TeamViewer: https://www.saotn.org/software-deployment-through-wds/
-
@NetworkNerd said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
It's one thing to install TeamViewer but another to register with your TeamViewer account and enable unattended access, enforce policy, etc. I thought even if you downloaded the custom MSI you still had to make an API call back to TeamViewer to register the device with your TeamViewer account.
This is already taken care of with the .msi installer. No issues there. The issue is actually getting the .msi to run at the end of the image deployment. From what I understand, it's supposed to do it at the first logon of a user... and when the image is done, it logs on to a local admin user automatically. Does the normal dance before the desktop appears, but never any teamviewer install.
-
@Tim_G said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
@NetworkNerd said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
It's one thing to install TeamViewer but another to register with your TeamViewer account and enable unattended access, enforce policy, etc. I thought even if you downloaded the custom MSI you still had to make an API call back to TeamViewer to register the device with your TeamViewer account.
This is already taken care of with the .msi installer. No issues there. The issue is actually getting the .msi to run at the end of the image deployment. From what I understand, it's supposed to do it at the first logon of a user... and when the image is done, it logs on to a local admin user automatically. Does the normal dance before the desktop appears, but never any teamviewer install.
Take a look at this:
https://community.teamviewer.com/t5/Community-Blog/Deploy-TeamViewer-Host-Modules-to-Thousands-of-Devices-via/ba-p/3031 -
@Eltolargo said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
@Tim_G said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
@NetworkNerd said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
It's one thing to install TeamViewer but another to register with your TeamViewer account and enable unattended access, enforce policy, etc. I thought even if you downloaded the custom MSI you still had to make an API call back to TeamViewer to register the device with your TeamViewer account.
This is already taken care of with the .msi installer. No issues there. The issue is actually getting the .msi to run at the end of the image deployment. From what I understand, it's supposed to do it at the first logon of a user... and when the image is done, it logs on to a local admin user automatically. Does the normal dance before the desktop appears, but never any teamviewer install.
Take a look at this:
https://community.teamviewer.com/t5/Community-Blog/Deploy-TeamViewer-Host-Modules-to-Thousands-of-Devices-via/ba-p/3031None of those are relevant:
@Eltolargo said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
This isn't a scenario in which deploying TeamViewer to networked computers is happening. The only way to do this is either via the imaging process of the PC, or manually after the image is deployed.
@Eltolargo said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
These computers are not on a domain, so cannot be deployed via GPO.
@Eltolargo said in Install TeamViewer during "oobeSystem" (pass 7) WDS:
I don't need to do anything with the .MSI itself. It is set up, customized, registered, unattended access, everything, exactly the way we need it already.
To clarify, the .msi is located on a network share. TeamViewer needs to be installed as part of the imaging process, automatically and without user intervention. Deploying TeamViewer TO the PC by any means is not an option, whether centrally or not.
The issue is that the TeamViewer.msi only installs if it's ran via an elevated CLI, whether it's cmd, powershell, vbs, whatever... it has to be elevated, and it needs to run so it can be installed if you know what I mean.
-
I've got one more trick to try:
I will try to create a scheduled task on the image itself before I do sysprep, that runs during logon, which runs fully escalated and privileged as a local admin user. It will run a powershell script that installs TeamViewer, ending with deleting the scheduled task itself.
This is all banking on the fact that a scheduled task survives a sysprep. I have never tried it.
-
@tim_g Did it work?
