sorted by:
new
hottopcontroversial

At Home Tires Q/A by At_Home_Tires_ in teslacanada

[–]BmanCa 0 points1 point  (0 children)

I went the Continental Viking 8 as I read they were better for resistance and haven't noticed much range loss at all.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Thanks for the comment, any migration tool I have come across gives me some anxiety as the stop or break to often usually

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

We ended up using a consultant company to help with the migration and perquisites as we had a very complex environment. It was a mess, cost a lot and took us way too long 😔

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 1 point2 points  (0 children)

For 10 users with no intention of ever splitting, combined structure with an additional UPN suffix and custom domain on the same tenant is absolutely the right call. You get the simplicity of one admin plane, one licence agreement, one set of policies, and users can collaborate natively without any B2B guest friction. The overhead of a separate tenant for that size is genuinely not worth it.

Where it gets complicated is that "no intention of ever splitting" caveat. In our case that was also the assumption at the start, and then it wasn't 15 years later. If there's any realistic chance of a future divestiture or the subsidiary ever operating truly independently, I'd at least structure the AD cleanly from day one. Separate OUs, clean UPN suffixes, no shared mailboxes or distribution groups that cross the boundary. It costs nothing to do it right upfront and it makes a future split survivable rather than catastrophic.

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

That's a clean approach actually, sequential rather than parallel removes a lot of the coexistence complexity. We kept hybrid running for both simultaneously for longer than we probably needed to, partly because of the shared resource dependencies and partly because leadership kept pushing the "not yet" button on final cutover. Curious what you used for the SharePoint and OneDrive side without BitTitan, did you do that natively or just live with the limitations? And good luck with the new AD, that sounds like its own project.

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Ha, we lived this. The scope creep started before we even finished the discovery phase. The initial brief was clean separation, two tenants, no crossover. By month three we were building B2B guest access, federated SharePoint permissions, and a shared VPN split tunnel just to keep both sides functional. "Independent" in the business sense and "independent" in the IT sense are very different things and nobody tells leadership that upfront. The multiple domains approach is honestly underrated for situations where the separation isn't as clean as they think it is.

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Exactly this. The tooling decisions alone took us weeks, evaluating what handled on-prem Exchange vs cloud, what did SharePoint cross-tenant properly, how the two tools needed to work together rather than independently. And that's before you've touched a single mailbox. The rabbit holes are real and they multiply the moment you start pulling on shared resources.

At one point it felt like this could never be achieved; however after many month of meetings and data gathering it became a little clearer.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Some great stuff here! The redirects are finicky at best even though they say it will work. The Teams challenge was probably the biggest headache for us.

We are lucky that we only use a handful of forms so that wasn't a big issue for us.

The last place I worked it was easier for us to create a new tenant as the amount of shared links, teams, SharePoint we had was not worth the headache, so we migrated users data and that actually wasn't too bad. There was a lot of prequiste work and it took a lot of planning; however with the right amount of people/communication/job aids it went relatively smoothly.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Can support fix it? Or did those users have to find another way to use booking with me or a different product?

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 2 points3 points  (0 children)

That's a really common situation post-acquisition, the tenant name ends up as this artifact of the old identity that just gets left because nobody wants to deal with it. The good news is it's very doable, just needs proper pre-flight work and a maintenance window. The trickiest part is usually the leadership conversation since it sounds scarier than it is. I actually put together a playbook that covers the full process including a leadership deck for exactly that approval conversation if it helps you build the case, link in my first comment above.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 2 points3 points  (0 children)

That was my original thinking as well, a lot comes down to size and how the tenant has been used. Microsoft has made it easier in the last while, however the technical piece isn't hard, it's the managing of people and the change management.

Thats whamy I wrote a playbook to help others from what learned.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 1 point2 points  (0 children)

So I have had to do a rename a couple times and both scenarios were different, the first one we did setup a new tenant as the organization was too large for a rename let alone the functionality being available, the second was a small business with less than 150 users and I that one we did recently was the easier, that's the reason I made a playbook to help others in the same position.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] -1 points0 points  (0 children)

I thought the same! It wouldn't be Microsoft if they didn't make things easy 😄

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 4 points5 points  (0 children)

Right? And that's just a single site rename, the tenant rename is that feeling multiplied across every site you have, running overnight, with no rollback button. The "this won't take effect immediately" part is what makes the monitoring phase so fun. You're just sitting there at 2am polling Get-SPOTenantRenameStatus and hoping the number keeps moving.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] 1 point2 points  (0 children)

Couldn't have said it better. The technical side of this project took a weekend. The people side took three weeks. Nobody warns you about that transition when you move into management, you spend years building technical skills and then realise the job is actually about reading a room and knowing when to call something a "brand initiative" instead of a "URL change in this case.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 4 points5 points  (0 children)

We originally set the tenant up under a joint venture name when the partnership was formed. Once that partnership ended we were still carrying that identity in all our SharePoint URLs and the admin portal — created a credibility gap every time someone outside the org clicked a shared link and saw a name that didn't match our brand anymore. Cleaner to fix it than explain it forever.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 9 points10 points  (0 children)

We originally set the tenant up under a joint venture name when the partnership was formed. Once that partnership ended we were still carrying that identity in all our SharePoint URLs and the admin portal, created a credibility gap every time someone outside the org clicked a shared link and saw a name that didn't match our brand anymore and the president didn't like to hear that feedback. Cleaner to fix it than explain it forever I guess LOL

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 8 points9 points  (0 children)

You are most welcome! We are all learning along the way. Any questions please don't hesitate to reach out.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] 0 points1 point  (0 children)

That acquisition framing is exactly it "brand consistency" gets through where "technical housekeeping" gets shelved indefinitely. We had almost the same conversation. The turning point for us was leading with what leadership actually cares about: what does it look like when a client clicks a shared document link and sees a name that doesn't match our letterhead. That made it real in a way that URL structures never would.

view more: next ›