Use PSEXEC to enable RDP on a machine

  1. psexec \\remotecomputername -u username -p password reg add “hklm\system\currentcontrolset\control\terminal server” /f /v fDenyTSConnections /t REG_DWORD /d 0
  2. psexec \\remotecomputername -u username -p password netsh firewall set service remoteadmin enable
  3. psexec \\remotecomputername -u username -p password netsh firewall set service remotedesktop enable

Notes:

To run the command as administrator use “-h”

  • Example –
    • psexec \\remotecomputername -u username -p password -h netsh firewall set service remoteadmin enable

To have it prompt you for a password so you don’t have to enter it in plain text don’t use the -p command

  • Example –
    • psexec \\remotecomputername -u username netsh firewall set service remoteadmin enable

Open an elevated Command Prompt and type the below commands. Once finished reboot.

dism /online /add-package /packagepath:”C:\Windows\servicing\Packages\Adobe-Flash-For-Windows-Package~31bf3856ad364e35~amd64~~10.0.14393.0.mum”

  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.

Solution:
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