Ok, not directly Exchange related but an issue I’d like to share. In one of my earlier articles you can read I’m working on on a project where we’ll be performing a cross-forest migration of accounts and Exchange mailboxes. Migrating the Active Directory user accounts is done using ADMT v3.1 with SIDHistory. No problem so far, until we noticed some migrated users weren’t receiving Group Policy Objects and experienced authorization errors from time to time. After identifying several users experiencing similar issues, we noticed the following common eventlog entries:
System eventlog (the number 3888 varied):
Event ID : 6
Source : Kerberos
The kerberos SSPI package generated an output token of size 3888 bytes, which was too large to fit in the 2e00 buffer buffer provided by process id 0. If the condition persists, please contact your system administrator.
The Application eventlog contained the following event:
Event ID : 1053
Source : UserEnv
Windows cannot determine the user or computer name. (). Group Policy processing aborted.
Turns out, Kerberos is the culprit. GPO processing aborted because their Kerberos information exceeded the maximum Kerberos token size. This problem may occur when users belong to (too) many groups (.. don’t ask). In addition, memberships coming from SIDhistory are also added to the token, roughly doubling numbers.
As MS KB articles 263693 and 327825 suggest, we raised the MaxTokenSize limited to 65535 (0xFFFF) in the following registry location (if the value is not present, create it as REG_DWORD):
HKLM\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters\MaxTokenSize
After a restart, all problems were gone. This isn’t a standard GPO setting; when required, you need to create an .adm GPO template yourself which is described in KB article 938118. Hope you’ll find this information useful to keep in mind when performing your ADMT scenarios at clients with excessive group usage.
We’ve run into the same issues. Did you apply this to the workstation or server?
LikeLike
You need to apply it to systems your users log on; In our case, we’ve applied the fix to workstations, but you may need to extend that to servers (e.g. terminal servers)
LikeLike
Thanks for the reply
Were there any visable knock on effects of increasing the token size? Increased logon times ?
LikeLike
No, but why bother investigating. The increased token sizes are only caused by Sidhistory; in time, post-migration, ACLs should be migrated too and you lose the “old domain” SIDs from the token. It should be functional; not increasing the tokensize results in non-functionality so thats a non-option IMHO.
LikeLike
Many thanks for your information. What is the effects others system enviroments change registry value ? Do you have any experience for this issue ?
LikeLike
No negative effect observed, except for bit bigger requests.
LikeLike