When running the AD Best Practices on Server 2008, you may receive the following error:
The AD DS BPA should be able to collect data about Group Policy Results setting “Access this computer from the network” from the domain controller <DCNAME>
Check the XML log file for a more detailed error message. It can be found by default in ‘Logs\BPA\Reports\Microsoft\Windows\DirectoryServices‘ in your %systemroot% as ‘DirectoryServices_EngineReport.xml‘. Look for a section called <Error>. There will be a Message section with a somewhat more useful error. In this case, it was ‘Some or all identity references could not be translated.’, which would indicate that a deleted account is still referenced somewhere on a GPO. Unfortunately it doesn’t tell you which GPO has this error.
To find the GPO at fault, open up Group Policy Management Console, and back up your GPOs manually. Right-click the Group Policy Objects container, and choose Back Up All. As it is backing up, it will eventually give you an error on whichever GPO has the outdated SID:
GPO: Default Domain Controllers Policy…Succeeded, but note the following issues:
[Warning] The security principal [S-1-5-21-940797813-2055044403-441284377-1536] referenced in extension [Security] cannot be resolved, but the task will continue.
Fix the referenced GPO, and re-run BPA.
When using the Active Directory Migration Toolkit, you may receive an error that a user cannot be moved while they have child leaf objects. This is usually due to the user tying a device to their Exchange account via ActiveSync.
To solve this, make sure you have the Support Tools for Windows Server installed. Open up ADSI Edit (adsiedit.msc), and browse out to the user object.
Under the user container will be another container, ExchangeActiveSyncDevices. Select it, and you’ll see a list of all associated phones for the user on the right pane.
Delete the phones one at a time (right-click, Delete). Once all the phone objects have been deleted, you can then delete the ExchangeActiveSyncDevices container.
Once this is done, you should have no more problems moving the user with ADMT.
While rolling out a new logon script, I started getting reports of an error message like this one showing up. Error 0x80005000 with a source of (null) isn’t particularly helpful. The particular section of code referenced in the error dealt with pulling a user’s group membership from LDAP, and mapping drives accordingly.
After stepping through the script, I found that it was bombing out on a group with a forward slash (/) in the name. The / was throwing off the LDAP query, since it is a reserved separator character. There are 2 fixes for this. You can either do a substring replace, and replace ‘/’ with ‘\\/’ (yes – double backslash slash), or you can do what I did and just rename the group in ActiveDirectory to not contain a /.
Say your AD root is ‘smashcorp.local’, and you have a child domains of ‘flowerco.smashcorp.local’ and ‘oilchange.smashcorp.local’ The oilchange domain was migrated into your AD directly from NT4, while the flowerco domain was already AD, so a new DC was created for it and it was kind of ‘copied’ into the smashcorp forest.
If you are a member of the Enterprise Admins group of smashcorp, you might notice that while you can manage oilchange just fine, flowerco throws some strange permissions errors (like being able to delete but not create GPOs) and is always nagging you for a password for operations. Running a dcdiag from a smashcorp DC gives you “failed test NetLogons” errors, and access denied errors on Services, frssysvol, frsevent, kccevent, and Systemlog.
After scratching my head over this for a couple of days, and getting tired of RDPing into flowerco, I finally found where Enterprise Admins was missing from flowerco. In AD Sites & Services, go into the Builtin folder and add Enterprise Admins to the Administrators group. Apparently this didn’t happen with the way flowerco was brought into the forest initially.
I was trying to finish migrating to a new Exchange server, and was running both machines in parallel. Everything had been moved from the old server except for the Recipient Update Services. When I attempted to move one of the services to the new server, I received error code 0xC0070560, “The specified local group does not exist.” This error code conveniently does not exist in Microsoft’s knowledge base.
Apparently during some other server and Active Directory moves, the Exchange Enterprise Servers group in the Users OU of the root domain was changed to a Universal security group. After changing the Exchange Enterprise Servers group back to Domain Local, I was able to point the recipient policy at the new server and proceed with the uninstall on the old server.