Forum Discussion
MicrosoftIntroducing the Best Practices guide for Office 365 ProPlus deployment
This is fantastic.
The deployment 'how to' technet articles were functional, but a best practice guide is just what we needed.
Thank you!!
The deployment itself is not that hard. The deployment tool is an executable with two switches and a configuration file. The configuration file has documentation that explains each section.
I was actually surprised to see the GitHub tool appear. Yes, it's handy for sure. But editing the .xml file is easier than learning powershell commands.
The challenge is applying this tool to multiple different real world scenarios. Your existing enviroment differs to mine, so the guide helps you make some decisions about who's getting updates when, how you are going to run the setup.exe etc. As for any application, so will do with SCCM, some with use Group Policy some may use a third party software deployment tool.
There's also the change in the servicing model for updates. Again, it's not hard, it's just different to how we've rolled out Office updates before.
-Sonia
Hi Sonia,
(I ended up writing a lot more than I expected so if you're a busy person please feel free not to read. :) Most of my words are actually not directed at you but the anyone in the Office team that has influence.)
Everything is not hard once you understand it. Everyone has different skills and different amounts of time to research, think on a topic, and test. My time for research and experimentation are very limited.
The first time I read over the documentation and consulted with my co-worker on it, we still had a lot of questions. And I've never gotten deployments to work from an SMB share, let alone do I have time to update that share with new versions. (Microsoft releases WAY too many updates across all their products. It's impossible to keep up.)
The GitHub tool appeared because there is a need for it. This guide even includes a link to the tool. This means Microsoft sees the value in it and recognizes there is a hole to be filled.
> The challenge is applying this tool to multiple different real world scenarios.
That's because the deployment system they've come up with is overly-complicated and not thought through well. It wasn't designed with the end-user in mind. An engineering team, or single individual, were tasked with coming up with a way to deploy this. They developed it in their bubble at Microsoft and then released it. Now, what, two or three years later, they're releasing a massive guide, on top of all their other documentation, to make up for the complexity.
With usability problems, you don't blame the user. That's not how you fix usability issues and more training is also not the answer (quite the opposite).
Here's an example for you of a team in Microsoft that made a lot of changes to their deployment methodology based on community feedback and observation. When the Server team announced Nano server, and released the first public previews, their original plan was to be as minimalist as possible: zero UI with an esoteric deployment method. I think they had it in their minds that it wouldn't be too hard. I mean, it was easy to them, right?
What happened? People complained, they asked for more assistance from MS (it needed to be easier), and there are now 100s (possibly 1000s) of blog posts on how to deploy Nano server. Instead of sticking to their guns and just writing more documentation, and releasing guides, they went to work and added a minimal and interactive UI to the server (this was a big no-no at the beginning), and they've recently released a comprehensive GUI tool that helps you create OS images to be used for deployment
The Office team could stand to see the writing on the wall and do the same: Make deployments easy.
- Chris,
Thanks for sharing your thoughts further. I'm a really busy person, but I'll always make time for someone who's prepared to make the effort to engage in a discussion.
I agree - the first lot of documentation was very minimal. It took me a bunch of searching, piecing things together and trial and error before I was truly comfortable with it. But that didn't feel very different to me than say learning powershell.
BTW the trick I've found with updates is to script them to update your source. Yes, that's another hidden gem not so easily found, I hear you.
In the long term, I think the Office Deployment Tool provides an easier way for smaller orgs to control the installation versions and updates of Office in their environment, and it's interesting to see the same tool applicable for larger orgs plugging into SCCM etc.
I get what you mean about the time to learn a new thing and the tools to do that though. I think the OneNote notebook was trying to help here.
Can I ask what you would suggest in terms of the deployment being easier? That's a broad term. I'm not asking you to be a Microsoft engineer, but if you specifically have some ideas on how this could be improved, I'd love to hear them.
Would the Deployment Tool have been better in your opinion if the training that came with it was better?
Or would you throw out the tool in favour of a different approach completely?
-Sonia