Office 365 Deployment Ideas

[petben]

Hello, how are you deploying Office365 nowadays, I am finding our PowerShell start-up script (that runs setup.exe and references a custom .xml) is failing, it always works when signed in, but at start-up if hangs and fails....only sometimes of course. MS have denied any responsibility and closed our support case.

 

So, we don't use SCCM, and we're using AD/GPO (not Intune), any ideas?

 

Thanks

[mavhc]

chocolatey package

 

[petben]

Thanks, i have briefly looked at chooclatey, is it paid for? simple to use? better than GPO?

[waynebev]

We use MDT on most of our sites, just add it as an application.

[petben]

Thanks, can you specify the custom .xml as part of the setup in MDT?

 

current PS command:

Start-Process "\\files\Office\Office365\Deployment\setup.exe" -ArgumentList '/configure "\\files\Office\Office365\Deployment\Office365Config.xml"' -Wait

[ThomL]

Could it be because you're using UNC path? Maybe worth copying the setup.exe & .xml files to a folder on the client and then running the PowerShell using the local files to see if this behaves itself?

[waynebev]

Yes I prefer to have the Office installer folder in the MDT Applications folder then just point the .xml to it. In MDT when you add an Application just put in the install command

[Olliedawg]

Yes I prefer to have the Office installer folder in the MDT Applications folder then just point the .xml to it. In MDT when you add an Application just put in the install command

[ATTACH=CONFIG]71585[/ATTACH]

 

Wayne beat me to it!

 

Yes

 

In your deployment share add office365 as an application (add source files)

 

Set the quiet install command to the custom xml (mine for example : setup.exe /configure configuration365.xml )

 

Create the task sequence to install the application

 

Should be simple as that

[waynebev]

What Olliedawg said!!! Love a bit of MDT

[mavhc]

Thanks, i have briefly looked at chooclatey, is it paid for? simple to use? better than GPO?

 

It's free, simple enough for me, main advantage is I can a) easily deploy 100s of packaged apps, and b) keep them updated

[petben]

If you’re using MDT how do u go about installing a new version? My current broken PS method can check for a new version, uninstall old and then install new. Used for 2019 to 365 move for example..

[ThomL]

Does the PS method work more consistently if you copy the packages to the client in the PS and then run them from the client rather than unc?

[Olliedawg]

If you’re using MDT how do u go about installing a new version? My current broken PS method can check for a new version, uninstall old and then install new. Used for 2019 to 365 move for example..

 

MDT will only really work for onprem stuff btw. As someone stated above Chocolatey may be an option if you have some sort of RMM or remote scripting tool.. I used senso for my remote users

 

You would create a task sequence which first runs setup.exe calling the xml to remove any versions of office.

 

I have used this and it works well for removing Office 2019

 

Apologies i cannot get the format right on this.

 

 

Then you would add a restart to the task sequence for good measure.

 

Then you would add the Install application which contains your Office 365 source files & setup.exe / xml to install 365

 

Are you using current channel 365? Wouldn't need to check for new versions then

Edited May 23, 2024 by Olliedawg

[petben]

Does the PS method work more consistently if you copy the packages to the client in the PS and then run them from the client rather than unc?

 

 

 

I dont even use a local source we were advised to use the MS source (tried both locations though during tests). I could try and copy setup.exe and config.xml to C: and then continue my install script referencing those files...?

 

The error is below if you have any thoughts (only occurs as staup script remember...:

 

"ErrorCode": 0, "ErrorType": "", "AppVErrorSource": "", "ErrorMessage": "", "ErrorDetails": "", "ContextData": "{\"message\":\"Run Inspector tool process\",\"Process\":\"InspectorOfficeGadget.exe\",\"Command\":\"deprovisionuninstall --displayname \\\"Microsoft.Office.Desktop\\\" --logfile 

and

"ErrorMessage": "", "ErrorDetails": "", "ContextData": "{\"message\":\"Failed to use PowerShell deprovision Appx package\",\"Error\":\"Remove-AppxProvisionedPackage : Cannot bind argument to parameter 'PackageName' because it is null.\"}"}    

[ThomL]

Are you able to share the full startup script? Someone might spot the issue - the second error message makes it seem that the cmdlet 'Remove-AppxProvisionedPackage' isn't being given a package name to remove.

[petben]

Do you mean the error log or startup script? The script is a single line

setup.exe /configure path to xml

 

Thanks

[ThomL]

I didn't realise sub-processes were being spawned by the setup.exe - I thought you were doing this with more lines in the script, that's annoying.

[petben]

Could it be because you're using UNC path? Maybe worth copying the setup.exe & .xml files to a folder on the client and then running the PowerShell using the local files to see if this behaves itself?

 

unfortunately this still doesnt work

 

C:\office\setup.exe /configure C:\config.xml

 

 

Microsoft have closed the case:

 

When executing the ODT setup tool logged in as administrator with the same configuration file, the product installs without problems, which confirms it's not an issue with the device status; not a problem with the setup tool.

 

Situation:

- As per several of our official articles, usage of ODT will require administrator privileges;

- SYSTEM privileges, while theoretically similar privileges to the administrator, have access to different functions and do not allow the same range of functions as the administrator privileges;

- The fact that the old ODT allowed you to install based on the PS script with System privileges does not mean we supported so in the first place.

 

Unfortunately we would not be able to proceed further.