Friday, July 29, 2016

The attempt to connect to http://.../powershell using kerberos authentication failed.

During the process of a pretty standard task, I ran into this problem with a clients SBS 2011 server.








To resolve;

  • I closed down all MMC applications (AD, Exchange, IIS, etc etc).
  • Opened Registry, browsed to HKCU\Software\Microsoft\ExchangeServer\v14\AdminTools
  • Backed up the Key, and removed the REG_BINARY item of NodeStructureSetting.



Once I reopened the Exchange Management Console, I was greeted with the following.

 Open IIS Manager, and Edit Bindings... on the Default Web Site

Here, I noticed that the http binding was set to a specific address. I edited this, and changed it to "All Unassigned" which replaces the IP Address with a *.

Restart IIS, and everything should be functioning correctly again.

Thursday, July 28, 2016

Netlogon folders missing from newly promoted DC

After I promoted a 2012 R2 server to a DC of a 2003 functional domain, I transferred all roles, and confirmed so multiple times, as I've been caught out with FSMO roles and Global Catalogs in my youth.

Everything looked good.
So I demoted the old 2003 DC.
Restarted the server, to join it back on the domain to transfer the last few shares overnight.
Couldn't communicate to the domain. Skip past all the basic troubleshooting (DNS server, etc), I'm logging onto the newly promoted DC to delete the old computer object as a "maybe", when I run into the following error. For all AD MMC applications.


Brilliant, I thought to myself. Immediately firing up a command promt as Admin, I ran dcdiag and noticed "failed" a few times flashed past my eyes in a rush. After scrolling backto the top, I notice the DcGetDcName called failed with error 1355 (as below).


This highlighted that during the promotion process, it didn't actually create the share for NETLOGON and SYSVOL, or the Scripts and Policies folders.

To resolve this;

  1. I browsed to C;\Windows\sysvol\sysvol\domain name\ and created the Scripts and Policies folders manually.
  2. Regedit: HKLM\SYSTEM\CurrentControlSet\Services\Ntfrs\Parameters\Backup/Restore\Process at Startup
  3. Locate the BurFlags DWORD and modified the value to D4
  4. I then restarted the File Replication Services on the new DC.
  5. This automatically shares the NETLOGON and SYSVOL 
No restart required, and I was able to get into all AD MMC applications, and join the domain again.

Clocks on client and server machines are skewed

After promoting a Virtual Server 2012 R2 server to Domain Controller on a 2003 domain, I was attempting to load Active Directory Users and Computers on the new server, where I was greeted with the following error.


Simplest way of fixing, was to turn off Time synchonization from the Integration Services within the settings of the VM in HyperV


After a reboot, the time was all sorted, and it continued to work.

Thursday, July 7, 2016

Redirect Computers and Users OU

To take the guess work out of technicians remembering to place the Computer in the correct OU to receive any custom Group Policies, I've been changing the default Computer OU for some time now.

To do this, is very basic and often overlooked.

Load Active Directory Users and Computers, enable Advanced mode, and browse to the OU you want the computers to be a part of, right click and go to Properties. Switch to the Attribute Editor tab, and locate distinguishedName (should be the last option).
Click on View and then copy the contents.

Next load Powershell as Administrator

Now type in the following command
redircmp "OU=Computers,OU=Company Name,DC=Domain,DC=local"
To enter the data from your clipboard into the Powershell window, simply right click the mouse on the window when you're ready for it, and it will populate.

Friday, July 1, 2016

Free/Busy Data with Exchange 2016

We setup a new Exchange 2016 server recently, and the client advised me that the free/busy data was not displaying correctly for the Room Mailboxes, that were invited.

Previously, a simple  Set-MailboxFolderPermission -Identity MeetingRoom:\Calendar -User Default -AccessRights Reviewer command would fix it.

The MeetingRoom calendar would remove the organisers subject, and replace it with their name. It would read like:
Gareth Harris
Meeting Room
Gareth Harris

The following commands are now required for Exchange 2016, and have been in play with Office 365 for a while now.

Using the command above, I set -User Default -AccessRights LimitedDetails
Then ran Set-CalendarProcessing -Identity MeetingRoom -AddOrganizerToSubject $false -DeleteComments $false -DeleteSubject $false

This will only effect new meetings.