Delete Windows.old from an upgraded Windows Server install operating in Core

I was at a customer site and they had a single Hyper-V host (running Server Hyper-V edition) and had done an in-place upgrade. Microsoft generally recommends you always do fresh installations and migrate, except for Configuration Manager servers where it is a supported configuration to upgrade Windows versions.  They were starting to run low on disk space on the C drive, so I’ve outlined the below process for removing the windows.old directory.  You can get anywhere from 6 GB to 15 GB back by removing the windows.old folder which is where everything Windows based is moved to if you decide to upgrade your Windows Server.

Download the SysInternals Junction utility which we will use to find and delete and directory symbolic links (or NTFS Junctions) that may still exist in the directory structure, expand the zip file and create a PowerShell file with the following code and save it under a C:\temp location (which is where we will work from).

foreach ($line in [System.IO.File]::ReadLines("c:\temp\junctions.txt"))
{
    if ($line -match "^\\")
    {
        $file = $line -replace "(: JUNCTION)|(: SYMBOLIC LINK)",""
        & c:\temp\junction64.exe -d "$file"
    }
}

The above code will iterate through the junction list we can extract with the below command.  On a majority of systems this should actually come back empty indicating that the Windows upgrade has gone smoothly.

junction -s C:\Windows.old > junctions.txt

We then execute the PowerShell file we saved earlier with the text file we just created with the Junction utility.  Once that is done we can begin to clean up.  Firstly, take owernship by issuing;

takeown /F c:\Windows.old\* /R /A /D Y

You may find that will be all you need and can issue the rmdir otherwise, run this additional command

cacls c:\Windows.old\*.* /T /grant administrators:F

So after all that I was easily able to reclaim a whole bunch of disk space by issuing the following command.

rmdir /S /Q c:\Windows.old

If only Microsoft kept Disk Cleanup on Windows Server to make life easier.

Renaming a Hyper-V Failover Cluster

If you find yourself taking over a cluster with a name that is silly or doesn’t make sense, you can rename it without much issue. Your main thing to watch out for are backup software that target the cluster (such as Veeam or DPM). You just need to ensure they are reconfigured to use the new cluster name. Also, if you happen to have VMM managing the cluster, make sure you remove it from VMM before doing the rename and then add it back in.

To do this, simply open up the failover cluster manager, right click on the cluster and click properties. Now you can enter a new name. Once done it prompts you to restart each node in the cluster and you should do that sooner rather than later to prevent issues.

Hope that helps.

How to Reset a Domain Controller’s Domain Admin password for a Virtual Machine running up in Azure

The Reset password utility for Virtual Machines has come in handy on the odd occasion when we never recorded or misplaced the password for a VM running in Azure. The downside is this tool does not support running against Domain Controllers (to reset the in-built Administrator account).  So what happens when you have a domain controller, that only has a single Domain Admin account and we’ve forgotten the password?  In comes Virtual Machines Extensions to the rescue.  Firstly, open up Notepad and enter a net user reset password command like below replacing the username and password with the one you want to reset.  Save it as script.ps1

net user <Username> <Password>

Log into the Azure Portal and then select the Virtual Machine  you want to change domain password for, under the main menu blade for that Virtual Machine find Extensions and enter it.  We now want to add in a new Extension so click on the +Add button at the top, in the Add Extension blade, find and select Script Extension and click on Create.

This will now allow us to upload the script.ps1 we created earlier, so browse to it and then hit Upload.  This will then trigger the script to run in the Virtual Machine and we’ll get notified when it is created and run.

Working with Windows File and Folder NTFS Permissions (Copy and Reset)

There have been a few times recently where I’ve had end users do some weird things to either their desktops or development servers they have been working on. If they’re on Dev servers we usually just restore the servers from backup but sometimes we just need to do a quick fix.  The most common issues I find are around permissions (web develpoers tend to muck around with c:\inetpub\wwwroot a lot).  I’ve got a few tricks up my sleeve to deal with it.

Copying permissions from on folder to another is straight-forward with PowerShell

Get-Acl -Path 'C:\DemoFolder' | Set-Acl -Path 'C:\NewDemoFolder'

Other times I find we just need to reset the folder permissions back to what Windows believes the default is

icacls * /T /Q /C /RESET

Another thing is sometimes ownership info needs to be reset too, you can do that with the following command.

takeown /R /F *

Hopefully that helps out.

Allowing DirectAccess to other internal Subnets or VLANs in your Network

If you’ve got DirectAccess running in your environment for remote access you’ll know how great and seamless it is for your end users. For businesses with large segmented internal networks we need to make sure that your external users can access all of the internal resources they need.

For this to happen we need to add static routes to our DirectAccess servers so that remote users can access these other networks.  Your DirectAccess server should have two NICs with one being the external and the other for your LAN, we add these static routes onto the LAN (as the Gateway has been defined on the External NIC only). We can issue the following PowerShell command to add a static route to an interface.

New-NetRoute -InterfaceAlias -DestinationPrefix -NextHop
an example is as follows
New-NetRoute -InterfaceAlias LAN -DestinationPrefix 10.1.10.0/24 -NextHop 10.1.1.1

This would allow any of our DirectAccess clients to access the 10.1.10.0/24 network even though our default internal network would be 10.1.1.0/24.

If need be you can use Remove-NetRoute to remove these static routes in future.

Reset the Default Domain and Domain Controller Group Policy Objects to their out of box state

So, I recently inherited a small client with SBS 2011 and their previous IT admin only ever used the Default Domain Policy to apply computer and users settings (such as mapped drives and printers). Microsoft has quite a strong recommendation of best practice for the two policies which goes along the lines of;

  • Default Domain Policy GPO should only be used to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy.
  • Default Domain Controllers Policy GPO should only be used to set user rights and audit policies.

So I first needed to create separate GPOs to store these custom settings and then a way to clear out all of those changes and revert them back to their default state.  So how do you go about reversing the damage if you don’t have backups far enough? In comes a small utility called dcgpofix which resets these two Group Policy Objects to their default settings. Launch an admin command prompt window and run the following command;

dcgpofix /target:both

Once executed it will confirm you want to restore them to their out of box defaults, which we can confirm with a couple of Y responses and then bang they should be restored, see the screen shot for an example of it running in my test lab.

How to easily Check your SPN and Delegation settings for SQL Server in an Active Directory environment

I was recently setting up some Linked SQL Servers for a customer to perform queries against a database on one server through another. One of the things you need to get right when setting up linked servers when using Service accounts in Active Directory is SPNs (or Service Principal Names) and Authority to Delegate (for Kerberos authentication) which can sometimes be quite cumbersome through ADUC or ADSI edit.

I then stumbled upon a little tool from Microsoft called the Microsoft Kerberos Configuration Manager for SQL Server. Running this little tool on the two SQL servers I could quickly and more easily see the SPNs (see picture to the right) and Delegation permissions.  As one server was quite old (and before my time) I could easily see that the SPNs configured for that particular service account were incorrect and the tool even allows you to fix this by generating the correct SPN. Hope that helps save some time in the future.

Fixing the randomly stopping WsusPool IIS Application pool and Windows Updates failed 0x80244022 error

I was recently assisting a client with an upgrade of their Configuration Manager (SCCM) environment up to the latest release of 1702 and as part of that we’re also going over it’s currently deployed functionality and making sure it all works. They recently noted that clients were no longer receiving updates and ran the Software Update functionality of ConfigMgr, which funnily enough also relies on WSUS to sync up to Microsoft (but not push out the updates themselves).

So when troubleshooting Updating issues, you need to check both the Software Update Point and WSUS, and lowe and behold the WSUS console kept on crashing. After checking the Update Services service, I then turned to IIS and noticed the UpdatedServices Application pool had stopped, so I started it and went back into the console but soon noticed it had died again. After reading some advice on the TechNet forums they suggested raising the memory limit of the Wsus Application Pool, which is done by selecting the Application Pool Name and then clicking Advanced on the right hand side or right click menu. Scroll down to the bottom of the Advanced Settings Window until you see Private Memory Limit (KB) and increase this from the default of 1843200 (which is 1.8 GB) to 4194304 (which is 4 GB). Make sure you have enough RAM allocated to the machine, if you are feeling courageous you can also set the value to 0 which does not set a limit.

After increasing the available memory to the AppPool, WSUS synchronized successfully and clients were now receiving updates

An error has occurred when trying to access IdpInitiatedSignOn.aspx to test SAML authentication on AD FS 4.0 (Windows Server 2016)

A working example of IdpInitiatedSignOn.aspx

So usually one of the first things I do after initially setting up an AD FS environment (among others) is to test the Metadata (navigate to https://your.adfs.server/ federationmetadata/2007-06/federationmetadata.xml which should return valid XML) and sign-in functionality using the IdpInitiatedSignOn.aspx method. For Server 2012/2012 R2 this page enabled by default but if we navigate to this page on Server 2016 we get the following error;

An error occurred

The resource you are trying to access is not available. 
Contact your administrator for more information.

The reason being is that this is disabled on Server 2016 and there is an extra step that needs to take place to enable it.

We can check to see the current status by issuuing the following command in a PowerShell window.

Get-AdfsProperties | fl

Scrolling down you’ll eventually see enableIdPInitiaedSignonPage which should currently be set to false, to change this issue the following command

Set-Adfsproperties -enableIdPInitiatedSignonPage $true

This enables the IdPSignonPage and allows us to test a login process for a SAML authentication supported application. Once this works I know I can safely begin to provision my applications to authenticate users against this AD FS server.

Get a list of users in Active Directory who have not logged in for specified number of days using PowerShell

A client is currently in the planning stages of doing a migration to Azure AD and Office 365 and one of the things we needed was a list of users who have not logged on in the last few months but are still active in our AD.

Well it’s PowerShell to the rescue again (with Visual Studio Code my IDE of choice) with the following snippet of code which will query an AD environment looking for accounts which haven’t been touched in this case for 90 days and give me a nice CSV of their name and last logon timestamp.

import-module ActiveDirectory 
$domain = "adatum.com.au" 
$DaysInactive = 90
$time = (Get-Date).Adddays(-($DaysInactive))
 
# Get AD Users with lastLogonTimestamp less than time specified and is enabled
Get-ADUser -Filter {LastLogonTimeStamp -lt $time -and enabled -eq $true} -Properties LastLogonTimeStamp |
 
# Output Name and lastLogonTimestamp attributes into CSV
select-object Name,@{Name="Stamp"; Expression={[DateTime]::FromFileTime($_.lastLogonTimestamp).ToString('yyyy-MM-dd')}} | export-csv Inactive_Users.csv -notypeinformation

Save the above into a PS1 and then run this on a server which has the AD PowerShell modules (usually one of your DCs) and will then create a CSV located where the script is with a list of all the users who are still enabled but haven’t logged on in your environment.