1 of 1 people found this helpful
This may or may not fix your problem but is probably a better way to go about what you're trying to do. I generally don't find it a good idea to include exes that already exist on the target system within the package especially as the primary "installer". Instead you should either use a dummy exe that just waits a second then proceeds to any commands in package boot or compress the files you need to copy into a self extracting archive which you then use as the main package and run your copy commands from package boot after it completes. I have several packages set up using a dummy executable and haven't had any problems with that method.
I'm not entirely sure why building the package eliminated the error but it appears to have worked.
I've compiled an inert executable and call that as the primary installer.
I've then added the mms.cfg file to the package and the robocopy commands to package boot.
Initial testing indicates this is going to work.
I found it much simpler to do this in group policy.
- First, copy the mms.cfg file to the NETLOGON folder on your DC
- Create a new group policy object in Group Policy Management
- Under Computer Configuration/Preferences/Windows Settings, open the Files node. Add a new file using the Replace action. Specify the source in the NETLOGON folder and the destination path on the client computer. Repeat for the SysWOW64 destination folder and close the editor
- Under the Scope tab of the GPO confirm that the Security filtering includes the computer accounts that should apply the GPO. This should be Authenticated Users by default, which includes all domain computers, but you can change it if necessary.
- Link the GPO to the OU that contains the computer objects that should receive the file
[Edited to provide more complete instructions]
Yeah, using GPO is the way to go with a simple file (re)placement, however our Infrastructure team (who own the whole GPO thing) don't believe it's the way to go and so I look for another way.