Gentle reader,
No matter what you want to do with calendars server-side in Exchange, you are going to need to become conversant in Exchange permissions. It's the devil's bargain: if you want to migrate all your calendar data and preserve its utility with guest lists and responses, then you need to be able to manage Permissions on your Exchange users.
So here we're putting out our best effort at a cookbook guide to Exchange 2013 permissions for migrations. Even though full-state calendar migrations will never be a purely cookbook operation we think this will get you there (and we have some field experience taking a couple of novices through it this way),
First: GLOBAL ADMINISTRATOR rights are NOT enough. These rights give you administration rights over Exchange / Active Directory, but they do not give you the rights to access mailboxes – which is what you will need to move in data and re-create state.
No matter what you want to do with calendars server-side in Exchange, you are going to need to become conversant in Exchange permissions. It's the devil's bargain: if you want to migrate all your calendar data and preserve its utility with guest lists and responses, then you need to be able to manage Permissions on your Exchange users.
So here we're putting out our best effort at a cookbook guide to Exchange 2013 permissions for migrations. Even though full-state calendar migrations will never be a purely cookbook operation we think this will get you there (and we have some field experience taking a couple of novices through it this way),
First: GLOBAL ADMINISTRATOR rights are NOT enough. These rights give you administration rights over Exchange / Active Directory, but they do not give you the rights to access mailboxes – which is what you will need to move in data and re-create state.
We’re going to take this in stages.
Background. Your ADMINISTRATOR account needs to be able to:
- Use REMOTE POWERSHELL to Log into Office 365
- Create a separate service account (this keeps your ADMIN function separate from your MIGRATION function)
- We call the Service Account EXSU. When you create it, make sure it is mailbox-enabled (you will be sending email on behalf of this account
- Grant EXSU three rights:
- Impersonation
- No throttling. This is relevant (i.e., in your control) only for on-premises Exchange. For Office 365 you will need to contact your Microsoft rep and explain what you are doing and ask throttling turned off for the duration of your migration.
- FULL ACCESS to mailboxes (this makes it easy to use OWA with this account to check the results for individual users in testing and migration)
Start POWERSHELL.
IMPERSONATION: You’re creating a ROLE called “_suImp8” that allows Impersonation and then assigning it to EXSU
THROTTLING: You’re creating a policy called SuThrottling Policy and then assigning
it to EXSU. (Otherwise Exchange 2013 might shut you off mid-migration)
FULL ACCESS: this grants access to ALL MAILBOXES in
your domain to EXSU.
Log in with your EXSU credentials.
You should see this:
You should see this:
This example shows access to Office
365. Obviously if you are going into
your on-premises or your own hosted domain, your URL and service name will be
different.
Now to test FULLACCESS go
to the URL box and modify it as I have with a user on your domain:
Hit ENTER
Now you will be prompted for your end user
mailbox credentials. Use the service
account (EXSU) and the password to access to the mailbox. This is where FullAccess comes in – you don’t
have to crack all of your end users' passwords!
NOW it should display your test users’
mailboxes in OWA
If all of these are successful, now you
can do a test insertion!
Congratulate yourself. Permissions are historically the worst learning curve in a migration.
No comments:
Post a Comment