Your statement confuses me. What do you mean by "normal non-profit tenant?
It is my understanding that TechSoup is the only way to apply for non-profit o365. And, that there are two donated subscription types for non-profits which are handed out depending on evaluation of your application. So, by my understanding…
We have a non-profit tenant that qualified for 300 donated Business Essentials subscriptions not E1.
Presumably you have a non-profit tenant that DID qualify for E1.
Sometimes text can read as argumentative - not my intention. I’m trying to understand.
There’s a non-profit type for folks who create a retail account and then go through TechSoup verification that’s different from direct TechSoup tenants. If you go to the “Buy a License” screen does E1 not show up for $0?
So as easy as Tenant Type sounds at one time there were over 20 different Tenant types. This is because there was basically 6 different types of Tenants and some had Business and Some had enterprise SKUs.
Microsoft has been working for a long time now to try to clean this mess up but they still have 5 standard paths. Sound confusing yeah well…
So let’s just say you were originally SKUed (yeah I made that up) in a tenant type that no longer exists it doesn’t mean your tenant type just disappears… instead it means you were updated or were at least supposed to be updated into another SKU.
You can find your current Tenant type by doing a Get-OrganizationConfig |FL and looking for the ServicePlan - even when you do find that good luck on getting a definition on what it means exactly as I have yet to see an accurate breakdown of the BPOS tenants.
I know this all seems complicated, it is… but if your able to get a few ducks in a row then you don’t have pain and agony.
For instance, If you’re a Not For Profit, do a Not For Profit trial to start your account, don’t do a standard E1 or Government Trial. - Pretty simple. If you do get into the wrong Tenant the only thing to do is vacate the Tenant and start over in the right one - Pretty ugly…
Also I don’t know about the 2000 licenses for Not For Profit, that could be. However I can tell you that I have personally worked on a Business account with 30,000 E1 and 8,000 E3 in the same Tenant. It was terribly slow but then that’s the cloud for you.
O365 user limits get a bit hypothetical in the church realm. I mean, 90% of churches have less than 300 people in the whole church! Even the majority of megachurches can still flop all their staff and elders into the 300 user limit with ample room to spare. If your church is like 8K to 10K, has a one pastor to every 100 people ratio, a large support staff, and attendance is increasing, then it’s an issue to be sure, but the user limit is otherwise moot.
You’re so right!
However, there are some pretty big not for profits out there where 2000 accounts just would not be enough - I’m not aware of Microsoft limiting any of them on licenses… it might be something new they are doing but I would think I would have heard of some backlash by now. It’s really hard to say though because things changes.
The Not for Profit licenses for churches are a no brainer if you ask me, The cost of recovering one failed database is usually at least half the cost of what a migration would cost.
Gary, we did a cutover migration 2 years ago and did not keep our on Prem Exchange server. The migration itself was relatively painless with a few gotcha moments.
Post-migration and after we decommissioned and turned off our Exchange server, recurring meeting invites could not be managed. If a delegate deleted an occurrence, it would remove it from the owners calendar temporarily, but the deleted meeting would come back. The delegate was never given an opportunity to send a cancellation notice either.
The exact error was “This message could not be sent. Try sending the message again later, or contact your network administrator. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-0x0004dc-0x000524].”
This caused us the most grief from doing a cutover migration. If you have the time/resources, the hybrid method Ed laid out may be the way to go.
A couple of other minor user related issues. A lot of our users depend on the Outlook auto-complete cache file, .NK2 file to send email correspondence. In a lot of instances, we had to manually copy/paste from the old location of this file to the new location for Office 2016.
In a few instances, when I uninstalled the older version of Office, (in our case it was 2013), the file associations got messed up. We had to manually associate Excel, Word, and PPT to the respectice doc types for those apps.
We were able to delete those old recurring meetings by using the light version of OWA for each delegate that needed to delete those older meetings.
Yeah - these are some of the things folks see from time to time.
A couple of options to consider for you Andy would be to remove Azure AD sync and convert to a cloud only domain. I know that’s not great but it stops AD from handling Exchange Attributes and by doing that you get rid of some of the issues you’re having. An alternative would be to add a hybrid Exchange server - You should still qualify for hybrid key.
Thanks Ed, we’re past those issues now as all old meetings were deleted and recreated, but you’re right, at some point we will need to get off of .local.
There is little reason to vacate the .local domain anymore. I know it was a Lync / Skype thing for a while; but, since everything Microsoft is moving towards a cloud first, cloud only platform I don’t see a good reason to jump on that wagon.
AD OnPrem → Azure AD bases everything on the Users Email address (UPN) which becomes a universal Identifier for every person. Since this is translated from OnPrem to Office 365 Azure AD it really doesn’t matter OnPrem domain looks like.
If your not planning to install Skype for Business OnPrem then don’t sweat the .Local domain… well unless you have some custom apps that is keeping your Apple computers from playing well there. Then you might want to consider it.
I’m a Huge advocate of moving to UPN-based logins everywhere. It’s more typing, but it’s consistent everywhere so users tend to prefer it over shortname anyway.
