This message was deleted.

you don't need to enable the office container. if not, everything just goes into the profile. some people want the ability to segregate the o/s from office, but if you have no need for it, just leave it unconfigured and you'll have only 1 vhdx to manage, that's how i did it.

I started down this route before o365 was supported on Windows Server 2019. I had a Windows Server 2019 build with Office 2019. I had an exception with Microsoft to allow o365 users to use Office 2019 bits. 99% of my users would be on-premises Exchange and the remainder o365. I wasn’t using ODFC for the on-premises users. Once Microsoft added support for o365 on Windows Server 2019, I had to break it apart into separate delivery groups for o365 and Office 2019.

I can tell you for certain that we're not going that route. This is a W10 VDA environment running Office 2016 for all users, even O365 users. The plan is to wait for all users to migrate to 365 and then roll out a new vDisk that has O365 Pro on it, and add them all to the Include group in the ODFC container. Nick, I see where you're going with that, but I do want to separate the OST from the Profile container. I'm thinking about disabling all of the current ODFC options (sync just the OST file, assuming that's possible), and leaving the rest of it in the Profile container.

you can do that for sure.

That certainly seems like the best overall solution, and I'm kicking myself for not thinking about this earlier.

that i don't know since i threw everything together. test test test...

We’re retail, 99% of my users are shift workers, and until Microsoft has an attractive SKU number, those users will probably always be on-premises Exchange. F1 is being kicked around, but that’s going to be an ugly experience for users that expect the traditional office suite.

We're in healthcare. I hate 365, personally, but that's the direction we're heading.

Interestingly enough, our CIO recently announced we're cloud-first and will be moving everything to Azure over the next few years. I don't know that they considered Exchange, I cannot see building Exchange in Azure and not consuming o365.

running exchange in azure? you must have a really good use case or a stupid cio

Yeah, that doesn't at all fit into the direction.

hope you all got a big checkbook, those azure bills are going to be hefty and MS will surely up the pricing every chance they get b/c they know they got you

That said, we're (read: management) still not 100% sure of our direction. We're definitely going 365, but still haven't committed to OneDrive. ShareFile is still in use and who knows when we'll be able to throw it in the bin and light it up.

People are making decisions on a golf course that don't understand.

that sux and you're the guy that needs to make it all work seamlessly

Pretty much. We're all in a bind over it.

I'm raising flags.

yea that when invoice comes in, don't be anywhere around

BTW, in case anyone was wondering, FSLogix apparently does not migrate settings from one container to the other. Just finished testing that bit,

i could have told you that, hehe. it doesn't migrate crap

Hey, I'd have tested it anyway just to be sure. 😄

they had a upm migration script a few years ago and killed it off and told you if you migrated migration to contact a contractor that did them....more $$$ not sure why they did it. i guess they didn't wanna be in the conversion biz

You could use UE-V to migrate settings to new profile containers. @Aaron Parker has a blog with the details.

I'm not terribly surprised. I'm thankful that I wasn't really pressured into migrating anything from UPM, since I don't believe it's worth it (in our case with such vanilla users).

if it helps, our current stance is still to separate the Office Container so we have IO flexibility in the future and there is no support for multiple sessions with O365 container when using Cached Exchange mode - so you need to be using sessions disks for Office Container (this is different than Profile Container)

Here's why I recommend using both containers: 1. Backup / Replication - deploying both allows you to replicate and/or backup just the Profile Container. However, larger environments may still need to replicate both for DR, as creating new Office Containers en masse in a DR scenario can obviously hit internet links hard 2. Muti-session - as soon as you have Outlook cached mode you can't support RW access to the Office Container across multiple sessions. Profile Container and Office Container manage multi-session differently, so you need to consider the differences in behavior and supported configurations 3. Caches - hopefully you never see issues with the containers, but if you do, the Office Container can always be re-created because it's just application cache, while the Profile Container has a much larger impact on the user if re-created 4. IO - you can split containers across different storage locations for different IO profiles. Granted don't see many customers doing this (we have 1) but it does give you options

Backup/Replication/IO are the three big reasons why I went this route.

You would need to explicitly set those options as Disabled, as most of them are enabled by default. See the ODFC log file

So enable the option, but leave the sub-option unchecked?

No, set to Disabled - each policy item that is

Man, I must need to sleep or something. What a stupid question.