A blog with focus on Windows 10 and cloud <solutions
RSS icon Email icon Home icon

  • Creating the perfect and fully automated reference image for Windows operating systems

    Posted on January 14th, 2012 By Andreas Stenhall + No comments

    A perfect reference image for Windows is fast to deploy, contains all security updates and all other necessary patches and possibly also applications like Office and least but not last is fully automated to achieve the best possible stability and to avoid the potential of manual errors. This guide is intended to show you how to build the perfect reference image ever made!

    NOTE: I have also posted this guide to TechNet Wiki where you find an improved version of this article (although the steps in the article found below is still valid): TechNet Wiki: HOW TO: Create the perfect and fully automated reference image for Windows operating systems

    There is no need to invent the wheel again as this can be achieved very easy in Microsoft Deployment Toolkit. Start by downloading Microsoft Deployment Toolkit and in the components section make sure to download and install Windows Automated Installation Kit. Start Deployment Workbench and off we go!

    Note: This guide applies to everyone regardless if you are deploying Window using SCCM, MDT or any third party deployment solution.

    1. In Deployment workbench create a new share for creating the reference image so start by creating a new one and name it like “Reference image build and capture share” or something of your choice.

    2. Add the OS install files (repeat for each OS you want to build for) into the operating systems folder. Always include the setup files so never install just a WIM file at this stage.

    3. Create a task sequence based on the Standard client task sequence (repeat for each OS you want to build image for).

    4. For each task sequence edit the task sequence to enable the existing but disabled “Windows Update” step(s).

    5. Edit the rules of the share by right clicking it and choosing Properties. The rules (customsettings.ini) should look like below. Replace the variables BackupShare and BackupDir with whatever the share name and directory to store the images are.

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    SkipAppsOnUpgrade=YES
    SkipCapture=YES
    DoCapture=YES
    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipUserData=YES
    SkipTimeZone=YES
    SkipFinalSummary=YES
    SkipSummary=YES
    SkipLocaleSelection=YES
    SkipDomainMembership=YES
    SkipComputerName=YES
    SkipBitlocker=YES
    SkipApplications=YES
    ComputerBackupLocation=NETWORK
    BackupShare=\\server\share
    BackupDir=Captures

    6. Modify the bootstrap.ini to look like the below information. Replace the variables according to what applies to your configuration.

    [Settings]
    Priority=Default

    [Default]
    SkipBDDWelcome=YES
    DeployRoot=\\server\share
    UserDomain=CONTOSO.COM
    UserID=username
    UserPassword=password

    7. Now add to the Rules (customsettings.ini) a section named like below. This sets that the Windows Update step will point to your WSUS server, where you are in control of everything that is released by Microsoft and thereby staying 100% in control of what is in your image.

    WSUSServer=http://nameofwsusserver

    8. To make sure that you get a separate name for each operating system you are building a reference image for edit each task sequence to contain a Task Sequence Variable named for instance:

    BackupFile=Windows7Enterprisex64.wim

    9. Update the deployment share to get boot ISO which you use to boot your virtual machine and start the build process.

    Remember to always build the reference image on a virtual machine to avoid potential problems related to hardware.

    You could also add the Office as an application in the Deployment Workbench and to all task sequences that require it to make sure that you have a rapid deployment image ready to go.

    Done! Happy deploying!

  • Busting the myths: Windows 7 require Windows Server 2008/2008 R2 domain controllers and raised functional levels

    Posted on May 26th, 2011 By Andreas Stenhall + 1 comment

    It seems a fairly common misconception is that to be able to use Windows 7 in a Windows or should I say Active Directory environment one need to have either Windows Server 2008 or Windows Server 2008 R2 domain controllers. There are also misconceptions about the need to raise the forest and domain functional levels to be able to use the full power of Windows 7. Neither of these are true.

    You can get all the same features if you are using Windows Server 2003 domain controllers and that is also regardless of which forest or domain functional levels you are running with. The most common misconceptions are:

    • Group Policy Preferences. Work very well in a 2003 domain. However you need to manage the group policies from a Windows 7 or Windows Server 2008 R2 machine using Group Policy Management Console found in the Remote Server Administration Tools.
    • BitLocker. To store recovery keys in AD you need to extend the schema. If you have a domain controller that is running Windows Server 2008 or later you have what it takes, if you are running Windows Server 2003 on your domain controllers you simply extend the schema.

    I must add that you get stronger encryption for Kerberos by using Windows Server 2008 domain functional level though but the bottom line is that the functionality of the Windows 7 client is the same regardless of forest or domain functional levels.

  • KB article now available for 20+ processors issue

    Posted on October 25th, 2010 By Andreas Stenhall + No comments

    Not long ago I posted about the interesting issue of Windows Deployment Server services not starting when having more than 20 logical processors on the machine. Now Microsoft have published the KB article for the problem regarding Windows Deployment Server service but  it also seems to affect ntdsutil as well. Again, running a deployment server or a domain controller on a server which has more than 20 logical processors is not very likely but still it’s kind of an interesting issue.

  • RemoteApps integrated in Windows 7 – does not need 2008 R2 fully

    Posted on October 19th, 2010 By Andreas Stenhall + No comments

    Just a quick tip that you do not need to have your entire RDS environment at the Windows Server 2008 R2 level to be able to utilize the nice integration features of RemoteApps in Windows 7. I am referring to the feature of subscribing to a feed of applications and thereby have a dynamic publishing of RemoteApps for the ends users, in the users start menu.

    To get this working all you need is a Windows Server 2008 R2 to host the RDS Web Access role, which then can include and publish RemoteApp sources that are based on Windows Server 2008 hosts (no R2 requirements there).

  • Killing the myths: Group Policy Preferences for everyone!

    Posted on September 20th, 2010 By Andreas Stenhall + No comments

    There is a very common misconception out there that Group Policy Preferences can only be created, managed and applied to your Windows machines if you are running your domain controllers with Windows Server 2008 or later. This is so NOT true.

    What you have to do if you are stuck on domain controllers running Windows Server 2003 is to install the Remote Server Administration Tools on a Windows 7 (or Vista) client machine, add the feature Group Policy Management and then create a GPO in the domain and edit it, configuring the Group Policy Preferences of your choice. Voilà!

    I do not know where this myth is coming from actually but the fact that GPO Preferences were introduced in Windows Server 2008 is the major reason I would assume.

  • AppLocker does NOT require a Windows Server 2008 R2 DC

    Posted on October 16th, 2009 By Andreas Stenhall + No comments

    Documentation from Microsoft regarding the new feature AppLocker in Windows 7 (and Windows Server 2008 R2) early stated that to be able to use AppLocker you must have a “Windows Server 2008 R2 Domain Controller to host the AppLocker rules”. I have seen this information several times since then and at a seminar I payed a quick visit to yesterday regarding Windows 7 this particular questions was raised.

    Of course I had to make sure what’s really going on here and I have now verified that AppLocker works perfectly fine in environments where there are only Windows Server 2003 DCs or Windows Server 2008 DCs. I can see no reason what so ever for AppLocker to require a Windows Server 2008 R2 DC to function. The only requirement is that you’re running Windows 7 Enterprise or Windows 7 Ultimate edition to be able to use th powerful feature of AppLocker.

  • Solve inconsistencies in the servicing store

    Posted on September 24th, 2009 By Andreas Stenhall + No comments

    Microsoft introduced a totally new servicing mechanism in Windows Vista and Windows Server 2008 which is totally component based. Sometimes information in the servicing store becomes corrupt and inconsistent. This state can cause hotfixes, service packs, security updates and other types of updates to fail.

    To solve this problem you can use the System Update Readiness Tool which just have been updated to work with Windows Vista SP2 and Windows Server 2008 Sp2 (it also works for previous service pack levels).

  • Be aware of a problem when renaming domain controllers

    Posted on September 20th, 2009 By Andreas Stenhall + No comments

    If you have renamed a Windows Server 2008 or Windows Server 2008 R2 domain controller you should be aware of  a problem. The problem is that a DFSR object is not renamed to the new name. This does not cause any problems until you remove the domain controller in question and after doing a demote or cleaning it up with metadata cleanup the object will become orphaned. So if you have renamed 2008 or 2008 R2 DCs you should follow the steps in KB2001271 to fix this.

  • When to troubleshoot blue screen crashes

    Posted on July 27th, 2009 By Andreas Stenhall + No comments

    The other day I got an email from a blog reader which contained the information of a successful analyze of a memory dump file which is generated when an infamous blue screen of death occur. The reader wanted me to give him the solution or point him in the direction of a solution. This got me into thinking. When is it worth putting time on doing blue screen analyzes?

    The content of the crash dump is maybe not that relevant after all. What is more important is how often and when the blue screen of death occurs. If the crash occurred just once or very seldom and randomly I would say that it might not be worth finding out exactly what caused the crash. Keep in mind that a blue screen could indicate a hardware failure, although driver problems are the most common cause for crashes.

    However if the crashes occur often or at when doing specific tasks you have all the reasons in the world to get to the bottom of the problem. In these cases I recommend following the guide for troubleshooting blue screen crashes.

    An interesting thing to note about blue screens that start occurring after for instance upgrading the OS from Windows XP to Windows Vista or Windows 7 is that the new memory management in the later operating systems might reveal problems in the memory modules that did not show when using Windows XP.

    Finally, whenever having problem with blue screens of death I would recommend upgrading the machine BIOS. Often there are compatibility and stability fixes which solves problems with hardware which might be causing you the problems you are experiencing.

  • WEBSPAPW = Microsoft IT Environment Health Scanner

    Posted on July 7th, 2009 By Andreas Stenhall + 1 comment

    I guess you’re wondering what the heck “WEBSPAPW” stands for and it is nothing but “Windows Essential Business Server Preparation and Planning Wizards”. Microsoft has now come to the conclusion that this tool as I’ve written before was not only used for EBS migrations but also for general health checks in Active Directory environments. This has resulted in the name change to “Microsoft IT Environment Health Scanner” which is built from the previous EBS tool.

    When running the Microsoft IT Environment Health Scanner you may find problems related to AD, DNS, replication and many other things and for everyone in charge of or controlling the IT environment this tool is strongly recommended. Read more on the EBS Blog.

    Download: Microsoft IT Environment Health Scanner