Windows 8.1 and Server 2012 R2 Update

Along with the usual “Patch Tuesday” updates last week (8th April) Microsoft also released the following updates:

Windows Server 2012 R2 Update and Windows 8.1 Update (KB2919355)

These are actually a cumulative update rollup and contain some new features.

Windows 8.1 features are detailed here

These updates should be installed to ensure future patches are received, see this from Microsoft –

Important All future security and nonsecurity updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed. We recommend that you install this update on your Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2-based computer in order to receive continued future updates.



Migrating Server 2003 IAS settings to 2008R2 NPS

I have been working with a client recently to uplift their Active Directory from Windows Server 2003 to Windows Server 2008R2.

As part of this project I have had to migrate various services onto new servers such as Certificate Services, Terminal Services Licensing and IAS. It was this final service that gave me a little problem that I though I’d share with you.

I followed the excellent TechNet article at which details exactly what to do:-

  • Installed the NPS  role
  • Copied IASMigReader.exe to the 2003 ISA server
  • Ran IASMigReader to generate the IAS.txt file
  • Copied IAS.txt to the 2008R2 Server
  • Ran netsh nps import ias.txt
  • Registered Server in AD

This all went to plan, when I checked the Network Policies and Clients on the NPS server they were all present and correct as they had been on the 2003 server.

But, when we re-pointed one of the client devices to use the new server authentication was denied.

On checking the event log on the NPS server I found some very helpful, detailed logs that showed that the correct policy had been triggered and the client was verified but the authentication had been discarded:-

Reason Code: 80

Reason: The authentication or accounting record could not be written to the log file location. Ensure that the log file location is accessible, has available space, can be written to, and that the directory or SQL server name is valid.

This seemed pretty clear – the log file couldn’t be written to, all I needed to do was work out where this option was set!

The settings are under the Accounting node in the NPS console.

I noticed straight away that the path was C:\WINNT\System32\Logfiles – this had obviously been imported from the old server and was never going to work!

 Under Log File Properties, click Change Log File Properties and set the correct path.

The reason the connections were being denied was because of the option If logging fails, discard connection requests.

Once I had Updated the Accounting Log File location we re-tried authentication and all was working as it had been using IAS on the 2003 server.

Hopefully this may save you some time if you import settings from an old server.

Remember to Sysprep your VM’s!

A quick post to warn you of something that many of you fellow pro’s are already aware of.

Working with a client to install Exchange 2010 SP2 in a new virtual environment we experienced the following error on attempting to open the EMC:-

error [0x145AAC30] executing command ‘Get-LinkedRoleGroupForLogonUser’

On initial investigation this appeared to be a “known Issue” after SP2, which I was sceptical of as I have now installed SP2 for a number of clients with no problems at all. Further investigation revealed the true cause of the problem to be linked to SID’s.

The client had created a Template Virtual 2008R2 Server for quick VM deployment, they were under the impression that it had been “syspreped” but it transpired that they hadn’t ticked the box to “Generalize” the server. Consequentially every server that had been deployed from this template had the same SID, leading to this problem, and potentially many more!.

More info on Sysprep here :

As luck would have it the new environment wasn’t yet in production so we were able to uninstall all the rogue servers and remove them from AD & VMware – this could have been a lot worse!

Be aware – make sure you use this option if you are preparing servers….