Depending on the situation there are four permissions your service account must have to
function successfully in either a migration or using Sumatra calendar tools:
1.
Impersonation
2.
Full access
3.
Read access to the GC
4.
Other details: Allow Log On Locally
In which situations are these permissions used?
This summarizes the types of permissions you must use when
using Sumatra calendar technology.
Situation
|
Use Permission
|
Notes
|
Migrating Calendar Data into Exchange
|
Impersonation
|
Resource mailboxes are Disabled accounts by default, so in a
full-state calendar migration they are ENABLED temporarily so that the
Sumatra process can populate data correctly.
|
“Faster simpler” ICS calendar migration to Exchange
|
Impersonation
|
|
Using the SuHoliday cmdlet or the Sumatra Pump on users
|
Impersonation
|
Putting holidays into user calendars requires only impersonation
|
Using the SuHoliday cmdlet or Sumatra Pump on resources
|
Full access
|
Why Full access in this case?
Impersonation will not work unless you enable the accounts. In a migration there are many reasons for
doing this, but for holidays that is a wasteful extra step. Use Full access.
|
Terminating an Existing User
|
Impersonation
|
It’s basically a migration in reverse, so you use the same
permissions as a migration
|
Removing broken meetings from resource or user calendars
|
Full access
|
Don’t mess around in this case.
You’re trying to scrub out bad data, don’t let low permissions get in
the way of a fast job.
|
Impersonation
Impersonation grants the service account permission to
‘send-as’, and ‘receive-as’ the user account.
Note, however, that impersonation works only when the account is
enabled. For disabled accounts you will
need full access.
To impersonate in Exchange 2010, create a new
ManagementRoleAssignment (called “_suImp8”) for your service account (called
“exsu”.)
new-ManagementRoleAssignment
-Name:_suImp8
-Role:ApplicationImpersonation
-User:exsu@cod.sumatra.local
|
Full Access, Send-as, Receive-as
Full Access grants the service account permission to access
the user account. Full access allows
you to read from and write to folders in both enabled and disabled
accounts. If you are just cancelling
meetings from the conference room, full access is sufficient. If you want to send mail on behalf of a
disabled user/room, you will also have to grant send-as receive-as (see the
next section)
To grant your service account (called “exsu”,) full access for a room (“crar210q”), use the
add-mailboxpermission cmdlet.
Add-MailboxPermission
-Identity: crar210q
-User: exsu@cod.sumatra.local
-AccessRights: FullAccess
-InheritanceType: All
|
Note that group policies sometimes prevent permissions from
being inherited. Please use Active
Directory Users and Computers (ADUC) to ensure the permissions were set! Find the account (crar210q) and right-hand
click to obtain properties. Select the
security tab, then advanced. (If the security tab is missing, select Advanced
Features under View.) You can check the
permissions, or the effective permissions.
You should not see deny checked!
Add Send-as, Receive-as
If you have to add send-as receive-as, here is the
commandlet
Add-ADPermission
“CR 101B”
-user: exsu
-AccessRights: genericall
-ExtendedRights:
"receive as","send as",
"ms-exch-epi-may-impersonate","ms-exch-epi-impersonation"
-InheritanceType: All
Read access to the Global Catalog
Many enterprises grant access to the global catalog if the
user is a member of the domain. If login
is failing, anonymous access is probably disabled (since Windows 2000
DCs). Make sure you are an authenticated
user.
Other Details: Allow log on locally
Make sure your service account is allowed to log on locally
(as in the Local security policy, or if you have multiple machines, set via Group
Management Policy, screen shot below.) Otherwise you will generate a 401 error.
Note that in the example above we have both a specific
service account and a Group of Service accounts. Using groups in this way is an effective
means of managing several accounts if you need to segment them for Exchange
data insertion.
Debugging Exchange 2010 Permissions Problems
Setting permissions correctly is one of the largest stumbling
blocks in the process. Here is a list of the HTTP errors, and ways to
debug (and fix) permissions.
|
HTTP
Response
|
Most Likely Issue
|
Solution
|
|
401
|
Service account not allow to “log on locally”
|
Grant permission to “log on locally” via group or
local security policy
|
|
The CAS and Mailbox servers are not members of
Windows Authorization Access Group.
|
Add all computers as members to “Windows
Authorization Access Group” in ADU&C.
|
|
BASIC authentication is not enabled for the EWS
virtual directory in IIS
|
Set Basic authentication in IIS; remember to restart
IIS
|
|
The "SERVICE ACCOUNT" is not authorized to
submit requests to the CAS Server
|
Create a new-ManagementRoleAssignment, and grant ApplicationImpersonation
rights to the service account. Also remember to check the service account creds
to ensure they password is correct. Paste the "ews url" into a
browser. Enter the service account creds, when prompted. Do you see a EWS
WSDL page? (Note: this could show up as a 500 error in some instances.)
|
|
500
|
The "test user" does not exist in Exchange
or
is not mailbox enabled
|
Verify account exists in the domain, it is enabled,
a mailbox user (try to access the account in OWA using the service account
credentials). If the account is
disabled, did you grant “fullAccess” to the service account?
|
|
The "SERVICE ACCOUNT" cannot impersonate
the "test user"
|
Verity there is a management_role assignment
"ApplicationImpersonation" (Ex10) or ExtendedRights:"ms-Exch-EPI-Impersonation","ms-Exch-EPI-May-Impersonate"
(ex07) for the SERVICE ACCOUNT that is applied to the server or the user you
are attempting to test.
|
Start with IIS Basic authentication on the EWSvirtual
directory. It’s the easiest to see / fix.
Basic debugging protocol – 401 error
Open a browser window, and try to open you EWS url. If you typically point to the load balancer,
point to one CAS server instead. Try to
open the ews url e.g.,
http://ex10/ews/exchange.asmx. You should be prompted for credentials. Enter the service account credentials. If the credentials are rejected, your service
account may not be allowed to log on locally.
If you can login, try to insert a “test” appointment using
suExchange. If you see a 401, it will be
due to basic authentication not set OR the CAS/MBX server(s) are not members of
windows authorization access group.
Issue: Service account not allowed to log on locally.
Here’s an easy way to confirm you cannot log on locally. Go to the cas server you pointed to in the
EWS url, and open up the Security event log.
Search for event ID 4625, keyword Audit Failure. You’ll know you have to grant log on locally
if you see your service account, with failure information “the user has not been grated the requested logon type at this machine”. If so,
allow the service account to log on locally via a group policy or local
security policy.
Issue: Basic Authentication not set
Look in the IIS logs. If
you see a 401 error, check IIS. If basic
authentication is disabled, enable it. Remember to cycle IIS: “iisreset /noforce.”
Issue: Computers are not members of Windows Authorization Access Group
If you are still getting a 401 error, ensure that ALL
exchange computers and domain controllers are members of windows authorization
access group.
Basic debugging protocol – 500 error
Issue: Service account does not have impersonation permissions or full
access
If
you are still getting a 401 error, try logging into an active end user’s
mailbox via OWA (like your own!) using the service account credentials. If you see an error in OWA:
Check the Application event logs on the CAS server for Event
ID 17. If you do, then create a “New-ManagementRoleAssignment” to grant the
service account ApplicationImpersonation permissions (see “Impersonation,”
above.)
