Office 365, Microsoft Teams, and OneDrive

[Nick Panaccio]

Are there any recommendations with regards to which layer to include these components in? It looks like Teams is now included in the latest Office 365 C2R bits (from what I've read), so I was thinking that O365 and Teams go into the same layer, with OneDrive going into the OS layer. Anyone else doing something similar?

[Gunther Anderson]

I was hoping somebody else was going to chime in here.  The rules I live by are, if it smells like Windows, put it in the OS layer, and if it smells like Office, put it in the Office layer.  So what you describe (OneDrive in SOS, Teams in Office) absolutely matches that.  But I have no direct experience with either.

[Nick Panaccio]

Yeah, that's what I figured. I thought that since Teams was now included in the O365 deployment tool directly that they'd be using the per-machine installation, but it's still the old per-user install, so Teams will have to wait until Microsoft releases a VDI-friendly install. OneDrive might be a pain for me, because I went through a lot of trouble to remove all traces of it in my OS layer.

[Gunther Anderson]

It's like the Pirate's code: they're more like guidelines anyway.  The real rule about "smells like Windows" is that if a piece of software is likely to be used as a prerequisite by multiple, independent app layers, put it in the OS layer.  .NET, MSVCRT modules, things like that that are fundamental enough that you know other programs will want to install them, pre-install them in the OS.

 

The other consideration for putting something in the OS is updates.  Roles and Features should go in the OS layer only because the OS layer should be the only place that Windows Updates are installed.  If you install a role in another layer, it becomes tricky to get just updates that impact that role in the layer where the role is, and inhibit other updates.  The updates might not even have that kind of separation, so you might never be able to get updates that pertain to that role.

 

I don't know that OneDrive meets either of those standards.  So I'd have no trouble with you putting it in an app layer, or the platform layer, just to see how it works.  It might work fine.  And, who knows, it might miss updates, but it might be sufficiently independent that it's not an issue.

 

The real rule about "smells like Office" is licensing.  That's the only insurmountable part about trying to splite up and recombine Office things: whether or not the product puts a record in the Windows licensing database.  Everything else is just files and registry keys, and we're already good at that.  Encrypted license files are an insurmountable obstacle for us.  Visio and Project touch the licensing database, but I bet Teams doesn't.  That too might be something you can absolutely just toss into a separate layer if you want.

 

And of course one of the strengths of App Layering is that you can try, and if it all goes to heck, you can just delete the versions/layers where you tried, and it's like it never even happened.

 

 

"According to the Code of the Brethren, set down by the pirates Morgan and Bartholomew, you have to take me to your captain."
"I know the Code."
-- Elizabeth Swann and Pintel

[Nick Panaccio]

Circling back to this, there are some unique challenges with Teams in App Layering. The ALLUSER install apparently does some sort of VDI check, so if you attempt to install it in an App Layer, the VDI check will fail. I got around this by creating the following registry key before installation, and removing it afterwards: HKLM\Software\Citrix\PortICA

 

The second issue - which may or may not be with my own environment - is that wmiprvse.exe consumes 100% of the CPU after rebooting post-Teams installation if installing it in my  Platform Layer (I was testing it for the Citrix keys there) or in my Office 365 App Layer. Creating a separate App Layer solely for Teams didn't exhibit the issue - and I tried the O365 layer multiple times, just to rule out something fluky.

 

I haven't had a chance to actually test the application in a finalized image, but at least the layer is now built.

[Richard Buffone]

I have not seen any other reports yet about wmiprvse.exe running at 100% CPU on an app layer. Googling around a bit and it seems to be something that is common outside of a layering or virtualized environment. If you let the packaging machine sit for let's say 30 minutes to an hour, do you see the CPU activity stop? It could be a situation where Teams is looking for some other application, feature, or service already installed and then needs to perform some configuration or clean up that takes a bit of time.

 

If the CPU usages does die down on the layer but jumps back on the layered image then we could take a look at this through a support case to see if it has anything to do with us. We would want to see if the problem is present with and without elastic layering enabled on the image. If it occurs on an image without elastic layers enabled then it could still be outside of our control since we would have no filter drivers running at that time. If it occurs only with elastic layering enabled then we have good reason to believe we could be causing this. In either case we would have a look to see if we are part of the problem.

[Nick Panaccio]

19 minutes ago, Richard Buffone said:

If you let the packaging machine sit for let's say 30 minutes to an hour, do you see the CPU activity stop?

Nope. In fact, it got so bad that I couldn't even get back to the logon screen of the VM. Even after CPU activity died down, something was hosed up on it. We're not using any elastic layers, either. Honestly, I don't think this is an App Layering issue at all, and more of a Teams issue. If I have to put this garbage app in its own App Layer, I'm 100% okay with that.

[Ryan Deschaine]

So.. where do i put OneDrive?

 

OS Layer

Platform layer

App layer

 

Where is it going to perform best?

 

Thank you all for your information

 

Ryan Deschaine