Whilst promoting a Windows 2012R2 server to a domain controller it got as far as ‘Replicating the schema directory partition’ and then nothing else happened. Now, this server has NetBios over TCPIP disabled which was causing the above problem. The quick answer to this is to use the long version of the username when entering the credentials for the domain controller promotion i.e. domainname.comadministrator and not domainadministrator More info here https://support.

All of my domain controllers are now server core unless someone can give me a very good reason to install Windows with a GUI, so far no one has given me a good enough reason. When deploying a new child domain this means we can now use some PowerShell goodness to create our new child domain. Pre-reqs Windows 2012R2 Server Core installed IP address set on the box and preferred DNS server set to the IP address of a domain controller in the parent domain

This is awesome. Would still like this to see this made much easier (as the author says towards the end of the article), but anyway this makes using Let’s Encrypt with Azure websites possible and relatively easy; https://www.troyhunt.com/everything-you-need-to-know-about-loading-a-free-lets-encrypt-certificate-into-an-azure-website/

To get the last Windows boot time using PowerShell V3 or later. Get-CimInstance Win32_OperatingSystem | select lastbootuptime,csname This will show you the lastbootuptime and computer name

Had an odd problem in a lab environment. The lab was only two Windows 2012R2 core domain controllers, fully patched and up to date and a WSUS server. For some reason SYSVOL was not replicating and I only noticed when I configured a GPO for WSUS and noticed that one of the DCs never registered in the WSUS console. AD replication was fine - a repadmin /replsum did not show any errors.

Over the Xmas period it would seem that someone deleted a computer account from AD. This meant that the user of that PC could not log in using that PC. This is a Windows 2008R2 forest so to restore the computer object; Get-Adobject -filter {samaccountname -eq “pcname$”} -IncludeDeletedObjects | Restore-Adobject The $ on the pcname is important - computer objects in AD always have $ at the end of the name as part of the samaccountname attribute.

I’m in the process of migrating data from an aging file server to a new shiny one. On the old server the NTFS permissions are all over the place so I really wanted to copy the data to the new server without the existing NTFS permissions and then apply new ACLs on the new server. I decided on Robocopy to copy the data. The command line and switches I used are;

To find the date when Windows was installed; Open a cmd window systeminfo | find /i “install date” PS C:Windowssystem32> systeminfo | find /i “install date” Original Install Date: 16/10/2015, 14:09:01

Certain groups within Active Directory are considered protected groups and are protected by AdminSDHolder. When a user becomes a member of a protected group it will no longer inherit permissions from its parent object in AD (usually an OU). This can mess up any carefully laid permission delegations you may have configured. Much more on AdminSDHolder here As an AD admin you may find that if you have been delegated permissions to , say, reset passwords of all users in OU you could come across a user who’s password you can’t reset.

Trying to keep up with job changes and ensuring users accounts are in the correct OU in AD can be problematic. In the environment I work in each team has their own OU (I’m not sure why it is like this, I suspect it’s a case of ’that’s the way we’ve always done it’). Anyway mine is not to reason why. So the good thing is that the descriptions for users are fairly well defined, for example someone in the 2nd line team the description is ‘Second Line Support Team’.