Thursday, February 23, 2012

PXE Boot files in RemoteInstall folder explained

When installing WDS for PXE Boot functionality a RemoteInstall folder will be created. Most of times I install this role on the SCCM/ConfigMgr server with MDT integration. It's also possible to use a different server for that, as long the ConfigMgr PXE service point is installed on that server also. In this post I will explain the PXE Boot files which are installed.

After installation, the following files and folders are available in the RemoteInstall folder:

SMSBoot
- abortpxe.com > Used when no advertisement is available
- bootmgfw.efi > (available in x64 folder only)
- bootmgr.exe > In Boot order this is file 3 needed
- pxeboot.com > In Boot order this is file 2 needed
- pxeboot.n12 > Can be used to skip the second F12 requirement (!)
- wdsnbp.com > In Boot order this is file 1 needed (!)
SMSIMAGES
- Boot.xxx00001.wim (WDS x86 boot image)
- Boot.xxx00002.wim (WDS x64 boot image)
SMSTemp
- A temporary folder for updating boot images
Stores
- This is the Drivers (Metadate) store

The following outlines the download process.

1. A client is directed (by using DHCP Options or the PXE Server response) to download Wdsnbp.com
2. Wdsnbp.com validates the DHCP/PXE response packet and proceeds to download PXEBoot.com.
Note: PXEBoot.com requires the client to press the F12 key to initiate PXE boot. One can rename one of the other PXE boot files (such as pxeboot.n12) to download Wdsnbp.com to a different file. 
3. PXEBoot.com downloads Bootmgr.exe and the BCD store. The BCD store must reside in a \Boot directory in the TFTP root folder. Additionally, the BCD store must be called BCD.
4. Bootmgr.exe reads the BCD operating system entries and downloads Boot.sdi and the Windows PE image (Winpe.wim).
5. Bootmgr.exe begins booting Windows PE by calling into Winload.exe within the Windows PE image.

And some additional information also:

When using DHCP Options for PXE Boot, Option 66 and 67 are needed. Option 66 must be the IP-address of your WDS server, Option 67 must be SMSBoot\x86\wdsnbp.com (which is the first file needed during the PXE Boot process).

The default pxeboot.com triggers an F12 requirement. The first F12 requirement is needed when Network Service boot is not on top of list in the BIOS boot order. The second F12 requirement is needed because of pxeboot.com, which is only needed when using Lite Touch Installation (LTI).

The second F12 requirement can be skipped however when renaming the default pxeboot.com to pxeboot.f12 and pxeboot.n12 (which means no F12) to pxeboot.com. After that the second F12 requirement is not needed anymore, also not for Lite Touch Installation (LTI). This must be done in both the x86 and x64 folder to make it functional.

More information about "Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007" can be found HERE

Friday, February 17, 2012

Microsoft Application Compatibility Toolkit 5.6 upload error

When installing Microsoft Application Compatibility Toolkit (ACT) it's possible to start inventory and application compatibility. ACT helps identifying which applications are compatible with Windows 7 (and Vista) operating systems. ACT is actually a collection of multiple tools. More about that HERE

In ACT it's possible to create an Inventory package, which can be deployed by Group Policy. That way an ACT Data Collector Service will be installed, which will running as long as configured in the Inventory package. The ACT service will collect application compatibility data and will send the information back to the ACT database.

But what to do when no data is returned? Just have a look at Event Viewer then. In my case there where a lot of ACT-LPS and ACTUpload errors. The ACT-LPS warning can be skipped, because it's not the problem here. The real problem is the ACTUpload error. This because I'm trying to upload inventory logs from Windows 7 SP1 devices.

The ACT v5.6 log processing server does not process logs gathered from Windows 7 or Windows Server 2008 R2 machines with SP1 installed. These logs are moved to the Failed folder on the log share and the data is not entered into the database. This is due to the fact that the ACT 5.6 database does not have an entry describing Windows 7 SP1 or Windows Server 2008 R2 SP1 and therefore does not recognize the operating system of the computer that created the log.

To resolve this problem, an entry describing Windows 7 SP1 or Windows Server 2008 R2 SP1 must be added to the ACT database's Dbo.OS table. This is described on Microsoft Support: http://support.microsoft.com/kb/2533953

It's possible also to change the Windows version in the XML files, which can be found in the [Log share]\Failed folder. A quick look in my file showed this in the 5th line of the XML: <OsInfo Id=”6.1.1” ...>
I manually changed that number to 6.1.0 and the file got imported correctly. Version 6.1.0 is for Windows 7, 6.1.1 is for Windows 7 SP1, but that’s not yet in the ACT Database. When moving files again from the [Log share]\Failed to the parent folder (one step higher) they will be in processed and placed in the [Log share]\Processed folder.

When application compatibility data is collected, check Send and Receive Data, and choose which data can be synced to Microsoft. In return you get compatibility information on all applications that other people have tested before.

Now you have a list of all applications with Windows 7 compatibility information! Just use it for free.

Tuesday, February 14, 2012

Using MAP and ACT for Windows 7 installation or migration

When migrating to Windows 7 you don't know if hardware is capable for that. Microsoft released a few tools for that, so you know if it's ready for Windows 7. These tools are Microsoft Hardware Assessment and Planning Toolkit (MAP) and Application Compatibility Toolkit (ACT). In this blogpost I will explain both tools and more tips and tricks also.

Microsoft Hardware Assessment and Planning Toolkit (MAP) is a tool that will help you prepare for a Windows 7 (or Office 2010) migration. It will help you inventory your hardware and verify that it's capable for that. MAP is an agentless, automated, multi-product planning and assessment tool for quicker and easier desktop and server migrations. Since there will be no agents installed, it uses WMI for inventory.

When starting inventory it's possible that Insufficient data is displayed. This because of non-existing objects or the're turned-off. It's possible also that firewall or WMI problems is the cause here. Most of times this can be found in the reports, which can be created. It will be saved as an Xlsx and Docx file. On the ClientAssessment tab (Xlsx) there will be errors like: Connection time out & Machine not found.

In Assessment Properties you can set custom settings for hardware requirements. That way you can decide yourself which hardware is ready for Windows 7 installation or migration. It can be used for other discoveries also. MAP can be download here: MAP v6.5

The Application Compatibility Toolkit (ACT) is a tool for inventory and application compatibility. It's kind of same as MAP, but it's strenght is on the application compatibility side. Not on the inventory side (we use MAP for that). ACT helps identifying which applications are compatible with Windows 7 (and Vista) operating systems. ACT is actually a collection of multiple tools.

In ACT it's possible to create an Inventory package, which can be deployed by Group Policy. That way an ACT Data Collector Service will be installed, which will running as long as configured in the Inventory package. The ACT service will collect application compatibility data and will send the information back to the ACT database.

When application compatibility data is collected, check Send and Receive Data, and choose which data can be synced to Microsoft. In return you get compatibility information on all applications that other people have tested before. Now you have a list of all applications with Windows 7 compatibility information. ACT can be download here: ACT v5.6

With MAP and ACT usage it's possible to check for installation and migration information and application compatibility! Just use it for free.

Wednesday, February 1, 2012

Microsoft Management Summit 2012

Every year around April there's a huge Microsoft event called Microsoft Management Summit (MMS). This event is the top in Management solutions build on Microsoft System Center. This year I'm attending MMS also. I was there before in 2009, and now 3 years later, I will return to Las Vegas. Happy to be at this great event again!


This year’s Tracks include:

  • Application Management – includes things like Windows Azure, System Center Virtual Machine Manager, System Center App Controller 2012, Operations Manager, and Performance Management.
  • Client and Device Management – includes things like Windows 7, Windows Intune, System Center 2012 Configuration Manager, System Center 2012 Endpoint Protection, WEDM, VDI, Cross-platform Management, Microsoft Application Virtualization (App-V), Microsoft Enterprise Desktop Virtualization (MED-V), Microsoft Desktop Optimization Pack (MDOP), Windows Internet Explorer 8, Windows Internet Explorer 9
  • Fabric Infrastructure Management – includes things like System Center Virtual Machine Manager, System Center Operations Manager, System Center Data Protection Manager, System Center Configuration Manager, and System Center Advisor.
  • Server and Virtualization Management – includes things like Windows Server 2008 R2, Windows Server 8, Group Policy, WSUS, PowerShell/WMI, System Center Advisor, AD, and Forefront Identity Manager.
  • Service Delivery and Automation – includes things like Service Manager, Service Catalog, Orchestrator, and Private Cloud.
Most of sessions I will follow are in the Client and Device Management section. Thanks to myITforum for above information!