Monthly Archives: March 2014

Workshop – Migrating from Windows XP to Windows 7 or 8.1

Published / by Rens Hollanders / Leave a Comment

We all know (as good technicians) that the technical support for Windows XP is coming to its end at April 8th 2014. For some time now I have been writing about topics related to Operating System Deployment, Microsoft Deployment Toolkit and Windows 8.1. And as of June last year I’ve followed a didactic course to become an Microsoft Certified Trainer, because I believe that sharing my knowledge, passion and enthusiasm for the work that I do, and the products I work with, could inspire others to do the same.

To put this into reality, my employer has enabled me to develop a two day workshop about migrating from Windows XP to another operating system platform, which can be either Windows 7 or Windows 8.1. The focus of this workshop lies on migrating from an existing operating system to a new one, -but that isn’t entirely necessary-. If you are interested in working with the Microsoft Deployment Toolkit this workshop also applies to you!

The topics that will be discussed within these two days are the following:

  • Concept of Operating System Deployment
  • Installing and configuring a Microsoft Deployment Toolkit environment
  • Migration scenarios
  • First steps in creating and building a reference image
  • Driver management
  • Userdata
  • Troubleshooting
  • Licenses

Requirements for this training:

  • A laptop capable of running Hyper-V and two virtual machines
  • Windows 8.1 Enterprise

Who may attend:

  • Basically everyone who wants to learn something about Operating System Deployment, but the focus lies mostly on IT Pro’s, System or Infrastructure Engineers

Where will this workshop be held:

  • On my employers head office, located in Wijnandsrade, the Netherlands.
  • Possible this workshop will be recorded and made publicly afterwards.

Unfortunately, international followers cannot attend this course at this moment. But in case you could not wait or you prefer to have more detailed information, please do not hesitate to contact me.Β 

More information:

If you are interested in participating in this two-day workshop, please visit the following link:Β http://t.co/2SAa2kx6PT

Thanks for reading! πŸ™‚

 

Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed

Published / by Rens Hollanders / 7 Comments on Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed

Yes that’s right. Tested it the past week when creating an reference image for a project. It appeared to me that every time when I’ve wanted to install the .NET 2.0 and 3.0 feature on Windows 8.1 via command line or in MDT using the “Install Roles and Features” step and have ‘slipstreamed’ a language pack in Windows 8.1 with DISM upfront, the installation went wrong due to the fact that the Sources\SXS folder could not be found. This is something I’ve already seen as a question on social.technet which also lead to this investigation

figure 1.1: Error showing in bdd.log

netfx04

For reasons unknown as we can see in the logfile the source path is changed from the value that I have specified to: C:\MININT\Sources\ while it should point toΒ “%DEPLOYROOT%\Operating Systems\Windows 8.1 x64 Enterprise\Sources\SXS”

So I’ve started some testing and debugging, tried different scenarios such as: copying files locally, using an cmd installation file etc. Nothing seemed to work when the language pack was installed. Therefore I’ve performed a deployment without any additional language packs and it came to my attention NET FX 3.5 installs correctly without any issues.

Now how did I get around this?

Basically there are three options to install the .NET Framework 2.0 and 3.0 on Windows 8.1

  1. Manual by hand from the GUI
  2. By command line using DISM
  3. By using the “Install Roles and Feature” step in MDT
figure 1.2: Using the GUI
netfx01
figure 1.3: Using the command line
netfx03
figure 1.4: Using the “Install Roles and Feature” step

netfx02

The way to get around this nasty ‘issue’ that DISM ‘sayes’ it can’t find the SXS source file location is to put the installation of NetFX before the installation of the language pack.

Currently I use the following scenario:

Added the Sources\SXS folder from the operating system I use (which is currently Windows 8.1 x64 Enterprise) as an application into the Microsoft Deployment Toolkit and within the application I’ve created the following cmd:

This will copy the Sources\SXS folder locally to the machine into C:\Temp and then executes the DISM command to enable the NetFx3 feature. At the end of my task sequence I perform a cleanup of some folders which deletes the content copied locally. I then call the cmd as command line for my application installation. Perhaps not the tidiest way to do it. But using cmd’s makes sure you can execute multiple commands just by starting one cmd. Instead of having to break things down in MDT with single command lines.

Another solution may be to put an Task Sequence Variable at the beginning of the task sequence called: WindowsSource which holds the following value (points to the following location) “%DEPLOYROOT%\Operating Systems\Windows 8.1 x64 Enterprise\Sources\SXS” and use the “Install Roles and Features” step.

Whatever you do, just make sure the installation of NetFx3 happens before the installation of a Windows language pack. And I’ve put a restart step after the installation of NetFx3 just to be sure. And since this is during the building of the reference image, time is not of the essence here. So having another reboot more or less doesn’t matter in this particular case.

figure 1.5: Task Sequence Variable – WindowsSource
netfx05
figure 1.6: Task Sequence Properties – “Install Roles and Feature” step

netfx06

Or use an application, like the script mentioned above:

figure 1.7: Application Properties
netfx07
figure 1.8: Task Sequence Properties – Install Application

netfx08

Hope this can be of help to anyone, if you have encountered something different. Have a different approach or just want ask something? Please feel free to contribute in the comments. Thanks for reading πŸ™‚

 

 

Direct Access – Automatic GPO configuration set’s outdated and incorrect WMI filter

Published / by Rens Hollanders / 4 Comments on Direct Access – Automatic GPO configuration set’s outdated and incorrect WMI filter

Just a quick post to inform you about the GPO’s that will be automatically configured when configuring Direct Access.

Today I’ve done a Server 2012 R2 Direct Access implementation, and part of this configuration is that the Direct Access Configuration Wizard will automatically create two Direct Access GPO’s in your Group Policy Management.

  • One for Servers
  • One for Clients
figure 1.1: Group Policy Management

gpo

However, the GPO for Clients is configured with a WMI filter, so that if the rules stated in the WMI filter apply, the policy will be set on the system.

figure 1.2: WMI Filters

gpo_wmi

The WMI filter containes two queries: The 1st query looks for the PCSystemType to match with the number 2, which represents an mobile device (either a laptop or tablet). The 2nd query verifies if the Operatingsystem ProductType, Version, and OperatingSystemSKU matches a number of possibilities:

as we can see here the second query, looks for machines which are: ProductType 3 (Server) which run: Version 6.2 (Windows 8) and have OperatingSystemSKU: 4 (Enterprise) or run Version 6.1 (Windows 7) and another set of SKU’s.

The odd thing here is that, although the Direct Access server runs on Windows Server 2012 R2, it configures WMI filters for Windows 8 and Windows 7, and not Windows 8.1. Also it configures in that same particular filter that the ProductType needs to match #3 which equals a server, and not a workstation (which represents the number 1)

Therefore I’ve modified this query into the following:

This way the WMI filter, filters accordingly to a Windows 8.1 Enterprise operatingsystem running on a Workstation.

Alternatively you can simplify, adapt er even completely remove the WMI query and just apply the GPO to a specific OU. However DirectAccess configures the GPO next to the default domain policy at the toplevel of the domain thus applying to all OU’s and Objects if it wasn’t for the WMI filter.

Hope this blog can be of use when configuring DirectAccess and prevent any delays when troubleshooting!

If there is anything you would like to share, please feel free to contribute in the comments

Thanks for reading! πŸ™‚