- This topic has 6 replies, 3 voices, and was last updated 6 years, 5 months ago by .
-
Posts
-
Same as this post: https://batchpatch.com/forum/topic/office-365-pro-plus-installation#post-82217
My Click Once script works fine interactively. I get the UAC pop up which I have to click yes and all works after that. This is done via a batch file.
Using BP to execute that script gives a success but it never installs. This is due to the UAC pop up that makes it hang.
I and the RunAs account have local admin rights on the machine.
I’ve used PDQ software to do the same thing and it works flawlessly.
What am I missing on BP or what can I try?
Yes, I can run windows updates and deploy other MSI or batch files successfully from BP. It’s the UAC that’s the issue.
I really don’t think the issue would/could be with UAC, otherwise we would expect to see the same problem occur with every single application or MSI etc that is deployed by BatchPatch, but we don’t.
To rule out the possibility that UAC is the culprit I would suggest disabling UAC completely as a test. If the exact same deployment works when UAC is disabled then it would indicate that UAC is, in fact, the culprit. Frankly, this would shock me, but do let me know.
Assuming that the issue still exists even when UAC is completely disabled, the next steps I would suggest are:
Try changing the remote execution context to ‘elevated token’ under ‘Tools > Settings > Remote Execution > Deployment’ and see if that makes a difference.
If it does not make a difference… In your deployment, can you confirm that your .xml file is in the same directory as the setup.exe on the BP computer? Can you also confirm that all of the other setup files that go along with the setup.exe are also in that same directory? If all of the files required for the installation are in the folder (with directory structure preserved, of course), then when ‘copy entire directory’ is checked, they will all be copied to the target computer so that when the setup.exe is executed, it will be able to find all of the files that it needs, including the .xml file. Make sure you have actually checked the ‘copy entire directory’ box in your deployment configuration.
Office 2016 Home & Business has got “click-to-run” installer.
AFAIK, no .xml is needed.
Starting the OfficeSetup32.exe or OfficeSetup64.exe should be sufficient.
OK, so you’re not executing a BatchPatch ‘Deployment’ action… you’re just using a ‘Remote Command’ in BatchPatch. I didn’t realize that. Certainly then one simple solution/workaround would be to use a BatchPatch ‘Deployment’ instead. I’m sure that this would work without issue. However, if you really don’t want to use a BatchPatch ‘Deployment’ then I have some questions and suggestions because UNC paths inside remote commands can be problematic.
1. You never tested disabling UAC even though you seemed quite certain that UAC was the culprit. While I don’t think that UAC is the culprit, I do think it’s worth disabling it as a quick test just to rule it out.
2. Are you using ‘Remote Command (logged output)’ or the regular ‘Remote Command’ ? Try both because they work a bit differently under the hood and can produce different results.
3. What is the exact command that you are executing? Without being able to see the command, it’s very difficult for me to really make a guess about what might be happening.
4. What exactly happens when you execute the command? You said it “gives a success but never installs.” Does this mean that in BP you see ‘exit code 0 (SUCCESS)’ or similar? Does this occur immediately after execution, or does it appear to execute for a while before returning?
5. There could be an issue with quotation marks (single vs double vs none) in the command.
6. It’s worth trying to supply ‘Alternate credentials’ for the row in BP even if the account you specify in the alternate credentials field is the same account that is being used to run BP. This is because when alternate credentials are supplied, the authentication does not rely on impersonation, which can create problems when trying to use UNC paths.
Thanks for clarifying. OK so in this case you are deploying the .bat file, but the .bat file is making network calls to UNC paths. This is effectively pretty much the same as using a BatchPatch ‘remote command’ to run the command, so for all intents and purposes much of what I said in the previous posting still applies.
So your options are:
0. Try disabling UAC as a test, as mentioned previously.
1. Try what I suggested in the previous post item 6 about supplying alternate credentials so that the remote process is not impersonating. This might solve the problem. IMPORTANT: Make sure to try this with all three ‘elevated token’, ‘normal’, and ‘system’ remote execution contexts. Let me know what happens.
2. Create a deployment to deploy Office instead of a deployment to deploy a .bat file. In this case you would configure your deployment to deploy the setup.exe, you would check the box to ‘copy entire directory’ and you would add to the parameters field “/configure configuration.xml” without the quotes. There are no UNC paths used in this method. The configuration.xml file will be located by the setup.exe without specifying a path because it will be found in the same directory as the setup.exe on the target computer during the installation. All required files are copied to the target, the installation is performed, and then the files are removed.
- You must be logged in to reply to this topic.