What tool for this project?

[HCHTech]

I'm planning a project to roll out about 24 new workstations, and I'd like to avoid manually installing all of the LOB software they need to contain. So I either need to image a fully-prepared workstation or somehow automate those installs. It takes about 2 hours to grind through the installs manually, so there is significant but not overwhelming labor to be saved. If it were a 500 workstation rollout, this would be a different conversation. With 24, falling back to manual processes isn't the end of the world, it's just more time-consuming. My "setup" procedure for the manual method has 45 steps.

The LOB software installers live on the network (and are updated monthly) and are dependent on the machine being already joined to the domain, so I think that rules out the sysprep route. The LOB software installers are also executables that can't be run from the command line, require several entries during the installation like network data paths (known in advance, but those paths have to exist at the time of install).

The problem with imaging is of course the SID would need to be changed - I've looked at SIDCHG, but don't have any experience with it, so don't know how risky this would be. MS's only sanctioned route is sysprep, and that doesn't work on domain-joined computers.

I've also looked at AutoIT, but I'm not sure I have the bandwidth to become fluent enough for that to be useful. I seem to remember back a long time ago there was kind of a "screen recording" software that created a script by "recording" a manual process that you could then compile and play back on other computers. I didn't use it, just remember reading about it. From my searching, I don't think such a thing exists now.

Am I missing something obvious? How would you approach this task?

Edit: I did find the Installshield trick of:

setup.exe /r /f1"c:\silent.iss"

which could then be played back on a different computer with:

setup.exe /s /sms /f1"c:\silent.iss" /f1"c:\software.log"

But in my case this didn't work since it appears the installers don't use Installshield. I have queried the vendor about this, we'll see if they respond with anything useful.

 

[YeOldeStonecat]

Does the software have an MSI version of installer? If so, and if this network is on a domain...Group Policy.

If not, and if they're on 365....have the 365 version of Group Policy Lite...InTune.

 

[trevm999]

I've never had an issue with a syspreping a domain joined system. Of course make sure you use the generalize option, and don't sysprep someone's active system.

 

[trevm999]

Issues with the Windows Store is another story.

 

[Markverhyden]

I've never had an issue with a syspreping a domain joined system. Of course make sure you use the generalize option, and don't sysprep someone's active system.

I've never had an issue either but my experience is also very limited. From what I've read over the years the concern is that many apps added beyond the base OS install add SID(s) to the registry at installation on the base image in audit mode. sysprep removes the M$ generated SIDs but the third party apps may stay in the registry. When launched at OOB on the target a new SID get's created so there's multiple SIDs for one app. And it get's even more complicated than that.

The SID debate: To Sysprep or not to Sysprep

The conventional wisdom is that third-party tools leave duplicate SIDs across PCs that create serious security holes. The conventional wisdom is wrong

www.infoworld.com

 

[trevm999]

I've never had an issue either but my experience is also very limited. From what I've read over the years the concern is that many apps added beyond the base OS install add SID(s) to the registry at installation on the base image in audit mode. sysprep removes the M$ generated SIDs but the third party apps may stay in the registry. When launched at OOB on the target a new SID get's created so there's multiple SIDs for one app. And it get's even more complicated than that.

The SID debate: To Sysprep or not to Sysprep

The conventional wisdom is that third-party tools leave duplicate SIDs across PCs that create serious security holes. The conventional wisdom is wrong

www.infoworld.com

Hmm, well there could be something to that. Service Principal Names need to be removed prior to domain joining. I was surprised that sysprep does not remove Group Managed Service Accounts, but those are designed to be used on multiple systems, Managed Service Accounts might be an issue though.

However, I feel like if anything like that is in use, the vendor should be able to tell you and that are then probably ways around those issues.

 

[trevm999]

Figuring out how to make it use a different SPN would sure beat having to reverse engineer the installer.

 

[HCHTech]

Well, I just happen to have a fully configured but not yet deployed workstation I can use for testing purposes, so I made an image of the HD, and tried to run a sysprep with the generalize option, but of course that failed. The relevant lines from the sysprep log are:

2021-02-14 18:41:02, Error SYSPRP Package AD2F1837.HPPrinterControl_122.2.834.0_x64__v10z8vjag6ke6 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
2021-02-14 18:41:02, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.
2021-02-14 18:41:02, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.

There is an HP Color Laser on the network, and the HP Smart App was installed (must have been auto-detected, as I didn't install it manually). I uninstalled the app and removed the printer, rebooted, and tried again, but got the same error. I can find no other HP apps installed, so I'm not going to tilt at this windmill any more today. Since I did load Windows updates, it's possible this error is the result of MS Store Apps updating before the sysprep attempt which is described here, but I'm not going to chase that for now.

 

[trevm999]

Yep, so that's one of the pita things with Windows 10 and the windows store.

If I remember correctly, what happens is that when Windows updates run, some apps are removed, however they are not completed removed for a user account until a user logs in, at least back when I was fighting with it a few years ago. In theory, if every user account that ever got registered on the system logs in, then it will clear up. You can also access the SQLite database for the Windows store and just delete that app entry for every user... however you will then run sysprep again and find a new package causing the issue, and the number of packages that were removed will be pretty much endless.

So the simplest option in that situation is to just nuke the whole Windows Store, and then do something to bring it back.

 

[HCHTech]

Yep, so that's one of the pita things with Windows 10 and the windows store.

If I remember correctly, what happens is that when Windows updates run, some apps are removed, however they are not completed removed for a user account until a user logs in, at least back when I was fighting with it a few years ago. In theory, if every user account that ever got registered on the system logs in, then it will clear up. You can also access the SQLite database for the Windows store and just delete that app entry for every user... however you will then run sysprep again and find a new package causing the issue, and the number of packages that were removed will be pretty much endless.

So the simplest option in that situation is to just nuke the whole Windows Store, and then do something to bring it back

Ha - this right here is what kills the Sysprep option, then. The time saved would be all spent dealing with this nonsense. I read some more about this problem, and the recommendation is to update with a local WSUS server while denying the workstation an internet connection, then running sysprep. This isn't really a reasonable option in my world. I'm going to try just imaging the fully-prepped workstation and then when I get the next one in restoring that image and changing the SID with SIDCHG or similar. If that causes problems, I'll probably just go back to the old way - it's like MS doesn't really want you to do this -

I could steer around this whole thing if I could script the installs of the various software. I understand PDQ Deploy might be an option, but I don't know how well it deals with custom software. They have 4 LOB apps made by the same vendor, 2 use SQL databases on the server, and 2 use access databases on the server. The vendor responses to my questions from last week will probably point to the "right" path to take here.

Also, I suppose folks that deal with 500 or 5000 workstation rollouts are using Win10Enterprise, which probably gives you more options. There is no way those levels of rollouts are not automated in some fashion.

 

[HCHTech]

Well, got my response from the vendor. After 3 paragraphs of "This is completely outside of the intended scope of our support agreement and would be an unsupported installation method" and "Don't call us if you turn your computer into a doorstop going down this path" language, they said there is a single "/s" flag they support which should do a silent install. Their settings are done via INI files, so theoretically, I could put correct versions of those in place with a script either before or after the installs.

Trying the /s install method, however, pops up a UAC prompt, so that's not really going to work out of the box. I would have to disable UAC prior to the install and re-enable it afterwards. Probably doable with a script as well, unless it requires reboots.

Another hurdle is that this client uses mapped drives still, and they are not available under an elevated CMD session. That is a fixable thing with a registry or GP change I'll need to investigate if it doesn't work to just use UNC paths via script. So I have some homework ahead of me.

 

[Tech Savvy]

Trying the /s install method, however, pops up a UAC prompt, so that's not really going to work out of the box.

Have you tried doing this command line via a script in your RMM, I think I saw another post that says you use solarwinds, I believe you have the option in SW to run as logged in user, admin, or System. Admin/System should bypass the UAC prompt since they already have admin privileges.

So the process would look like this:
1. Create GP to install your RMM after they join the domain. (I know this is possible with SW because I used to do it on most of my clients when I had SW, if you need a template let me know I still have the policies they are just disabled for my clients)
2. Create a network share to host LOB installer.
3. Create script in RMM to install LOB app from the network share. I believe scripts will run at whatever permissions the SW service is running as and there is a way to change this if its running as a user with insufficient permissions.
4. Setup computers and join the domain as you mentioned
5. Your RMM will auto install.
6. Run script to install LOB, which can probably be automated via an automated task. on checkin.


Obviously it would be great if you can setup installer arguments or copy ini file or even create/modify INI via the script based on the user or device name or OS..etc