1. Log into your Domain Controller
  2. Run Powershell as Administrator
  3. Type the below command to move your roles

Move-ADDirectoryServerOperationMasterRole -Identity “Target-DC” -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator


**Also keep in mind in a single domain/forest with two domain controllers the roles should be split as follows

  1. Domain Naming Master, and Schema Master
  2. RID Master, PDC Emulator, and Infrastructure Master


Ran into an issue with a machine running Server 2012 and Windows Update continuously searches for updates without ever completing. Looked at the WindowsUpdate.log and found the following error

  • FATAL: CNetworkCostChangeHandler::RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002

Digging deeper I found the Desktop Experience Feature was Installed. Uninstalled the Desktop Experience Feature and low an behold Windows Updates now works properly!

  • PS C:\Users\administrator> Get-WindowsFeature Desktop-Experience | Uninstall-WindowsFeature

    Success Restart Needed Exit Code      Feature Result

    ——- ————– ———      ————–

    True    Yes            SuccessRest… {Desktop Experience}

    WARNING: You must restart this server to finish the removal process.

Got a call from a client today that was in an Office 365 to Exchange 2010 on Premise Hybrid deployment. Users in Office 365 were unable to see Free/Busy information for on Premise users. I was able to get it resolved by doing the following steps.

  1. Logged into http://www.TestConnectivity.Microsoft.com and tested the Free/Busy… Passed
  2. Logged into Exchange 2010 CAS server, opened EMS and ran “Test-FederationTrust -UserIdentity mailboxname -Verbose” . Everything also passed
  3. Checked the sharing policy on Exchange 2010 EMS and Exchange Online “Get-SharingPolicy | FL” . There was a small difference in the Exchange online so I added the Anonymous access by using the “Set-SharingPolicy” Command
  4. Checked the Permissions on the Virtual Directory on Exchange 2010 by running “Get-WebServicesVirtualDirectory | FL” . WSSecurity was enabled but I read that by refreshing the command some people were able to fix their issue, so I ran “Set-WebServicesVirtualDirectory -Identity “<HybridServer>\EWS (default web site)”-WSSecurityAuthentication $true”  Also did the same for AutoDiscover “Set-AutodiscoverVirtualDirectory -Identity “<HybridServer>\Autodiscover (Default Web Site)” -WSSecurityAuthentication $true”
  5. Then I refreshed the Metadata in Exchange 2010 EMS “Get-FederationTrust | Set-FederationTrust –RefreshMetadata”
  6. After that I reset IIS on all CAS and MBX servers and sometime after that everything started working properly again.

Ran into an issue today with a client running Exchange 2010 in a Hybrid configuration with Office 365. Exchange Online users were not able to see Free/Busy information for On-Premise users. Strangely enough the below resolved the issue even though everything was already configured correctly.

From the On-Premise EMS I ran “Get-WebServicesVirtualDirectory | fl” and it showed WSSecurity being enabled but I re-ran the command as follows

Set-WebServicesVirtualDirectory -Identity “<HybridServer>\EWS (default web site)”-WSSecurityAuthentication $true

I also checked the Autodiscover IIS virtual directory but it also showed WSSecurity being enabled

Get-AutodiscoverVirtualDirectory | fl

Re-ran the same command

Set-AutodiscoverVirtualDirectory -Identity “<HybridServer>\Autodiscover (Default Web Site)” -WSSecurityAuthentication $true

Then I performed an IISRESET . After that Free/Busy information started to work properly.


If you are having a problem soft matching Office 365 Users with AD connect you can Hard Match them by following the information below

  1. Move the troublesome user into an OU that is not being Synchronized
  2. Force AD Connect Synchronization
    1. Start-ADSyncSyncCycle –PolicyType initial
  3. Connect to Office365 Powershell and delete the deleted users from the Recycling Bin
    1. get-msoluser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force
  4. Log into the Domain Controller and find the users ObjectGUID.
    1. Open an elevated Command Prompt
      1. ldifde -f export.txt -r “(Userprincipalname=*)” -l “objectGuid, userPrincipalName”
    2. Open the txt file and find the troublesome user. Copy their ObjectGUID
  5. Go back to the Office 365 Powershell and set the Cloud Users Immutable ID to match the ObjectGUID you just found
    1. Set-MsolUser -UserPrincipalName User@domain.com -ImmutableId g9Pclm4vpk+vFWtMARklmg==
  6. Force AD Connect Synchronization
    1. Start-ADSyncSyncCycle –PolicyType initial

Here’s what to do if you your Windows 2008 R2 Server gives you the error Bootmgr is missing Press Ctrl+Alt+Del to restart:

  1. Either put in your Windows 2008 R2 CD or mount the ISO
  2. Boot to the CD and choose to Repair
  3. Go through all of the steps to get to the option to go to command prompt
  4. Enter said command prompt
  5. You’ll start at x:\sources\
  6. cd x:\sources\recovery
  7. run StartRep.exe
  8. This will start a repair. Let the repair continue until it is done.
  9. Run the repair again, even after a reboot and into the CD again if you need to.

Today I was working on a SQL Express database. The issue was domains were changed and nobody updated the permissions on the database prior to moving domains. When attempting to gain access to the database through SQL Management Studio I got error messages like

“the server principal is not able to access the database under the current security context”

Even attempting to change the sa account or alter in anyway I got message like the one below.

“cannot alter the login sa because it does not exist or you do not have permission”

The solution was to use PSExec and open management studio with the system account and then replace the permissions.

  • Download PSExec.exe and place into Windows\System 32
  • Open the command prompt as the administrator
  • Execute SSMS from the command prompt on the machine hosting the SQL database using the following command
    • PsExec -s -i "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
    • Note that the path to SSMS may be different depending on the configuration of your system
  • There are a few other caveats listed in the original article linked above
    • UAC may need to be disabled (worked Ok for me still enabled)
    • Your account needs to be a local admin for this work
    • May or may not work remotely


BIG Thanks to Shrout1