Last week we released Exchange Server 2010 Service Pack 1. It has received some great feedback and reviews from customers, experts, analysts, and the Exchange community.
The starting point for...
Updated Jul 01, 2019
Version 2.0
Blog Post
Just did some more research on this issue and this is what I found out:
It seems that EMC is searching for the machine SID (and not the DOMAIN SID for that computer) - probably as a bug fix to the KB981033 issue (customers who put dots in their computer Netbios names - who would ever do that?!#.)
In my case the machine SID was the same on all virtual servers:
S-1-5-21-401783670-1437582426-1158247984
(same result you get when running psgetsid without any parameters)
All my virtual machines were of course cloned before they ever joined a domain. As my child wisdom told me a machine will get a unique domain SID when it's joined to a domain - even when several machines with the same machine SID are joined to a domain they will always get a unique domain SID. Hence when I run:
psgetsid DOMAINMACHINEACCOUNT$
The results are all different:
DC1:
S-1-5-21-401783670-1437582426-1158247984-1000
DC2:
S-1-5-21-401783670-1437582426-1158247984-1103
MAIL1:
S-1-5-21-401783670-1437582426-1158247984-1105
MAIL2:
S-1-5-21-401783670-1437582426-1158247984-1104
MAIL3:
S-1-5-21-401783670-1437582426-1158247984-1601
When I go through adsiedit and check the "objectSid" attribute of all the computer accounts they are indeed the same unique values that psgetsid DOMAINCOMPUTERNAME$ gave me from the command line.
It clearly looks as this is a huge bug in the EMC. The search that it does in the background should have been based on a full ldap-path, objectSid (the domain one), objectGUID or something else than the local machine SID.
It seems that EMC is searching for the machine SID (and not the DOMAIN SID for that computer) - probably as a bug fix to the KB981033 issue (customers who put dots in their computer Netbios names - who would ever do that?!#.)
In my case the machine SID was the same on all virtual servers:
S-1-5-21-401783670-1437582426-1158247984
(same result you get when running psgetsid without any parameters)
All my virtual machines were of course cloned before they ever joined a domain. As my child wisdom told me a machine will get a unique domain SID when it's joined to a domain - even when several machines with the same machine SID are joined to a domain they will always get a unique domain SID. Hence when I run:
psgetsid DOMAINMACHINEACCOUNT$
The results are all different:
DC1:
S-1-5-21-401783670-1437582426-1158247984-1000
DC2:
S-1-5-21-401783670-1437582426-1158247984-1103
MAIL1:
S-1-5-21-401783670-1437582426-1158247984-1105
MAIL2:
S-1-5-21-401783670-1437582426-1158247984-1104
MAIL3:
S-1-5-21-401783670-1437582426-1158247984-1601
When I go through adsiedit and check the "objectSid" attribute of all the computer accounts they are indeed the same unique values that psgetsid DOMAINCOMPUTERNAME$ gave me from the command line.
It clearly looks as this is a huge bug in the EMC. The search that it does in the background should have been based on a full ldap-path, objectSid (the domain one), objectGUID or something else than the local machine SID.