Using BigFix to Migrate to Windows 10

Adopting and migrating to Windows 10 is a significant project. This Process will enable enterprise environments to move from older Windows systems (XP/Win7/Win8), regardless of 32 or 64-bit into the 64-bit Windows 10 and enable UEFI (remove legacy BIOS) in an automated fashion.

Most environments have been doing this as a manual process which often is very time consumptive and inefficient.  In addition, a simple in-place upgrade does not take advantage of UEFI and 64-bit. In order to take advantage of all the features in Windows 10 and migrate a user there are two stages to deployment. They are:

Analyses – Review of the current environment.

• Validate the endpoint is compatible to move to Windows 10
• Validate the BIOS are up to date and ready for update to UEFI
• Check if the endpoint is still under warranty and or about to expire, so client can make decisions on HW refresh
• Check all applications on the endpoint for 64-bit compatibility

Adopting and migrating to Windows 10 is a significant project.

Process Automation

A high level view of what actions need to be performed and can be automated to complete a full upgrade to Windows 10.

• Capture the current user-state (includes all users personalization on the endpoint)
• Backup the data on the endpoint device
• If all the above is in a “ready” state, then format the hard drive of the endpoint
• Load Windows 10
• Restore user-state
• Redeploy on previously deployed software (switch to 64 bits where applicable)
• Rejoin device to domain into the AD path where it existed

Desired State

When migrating to Windows 10, you may want to determine what the endpoint will look like in the end.  Microsoft’s minimum recommendations for Windows 10 are:

• Windows 10
• 64 Bit
• UEFI

Although you may have additional items such as:

• SecureBoot
• TLS
• etc.

Planning is essential in this endeavor and clearly identifying what the “Desired State” will be once an endpoint is migrating.

Master Action Site

Initial Setup – Initially, we will need to create some sites, fixlets etc. to automate the process.

Master Action Site -There are a few fixlets that must go into the master action site for this process. Adding fixlets to the master action site allows the fixlets to be run at a higher priority than any other site. The fixlets that must be added to the master action site are:

Master Action Site Fixlets

W10 Update Unsupported Windows10 Models – This fixlet will add any unsupported models you may have, and the analysis and process automation will skip these models.

W10 – Create Private Key for Windows10 Workflow – This fixlet creates encrypted username and password for the UNC share used for UserState Capture/Restores.

Master Action Site Groups

Two automatic groups need to be created. They are:

1. W10_POST and W10_PreEvaluation. W10_PreEvaluation – Relevance: (version of client >= “6.0.0.0”) AND ((exists true whose (if true then (exists (operating system) whose (it as string as lowercase contains “win” as lowercase)) else false)) AND (exists true whose (if true then (not exists (operating system) whose (it as string as lowercase contains “win2” as lowercase)) else false)) AND (not (exists true whose (if true then (member of group 83 of site “actionsite”) else false))))
2. W10_POST – Relevance: if (exists setting “W10STATUS” of client) then (exists setting “W10STATUS” whose(value of it as lowercase is contained by “post|basesoftware|optionalsoftware|joindomain|userstate|final”) of client) else false

Custom Sites

Two sites are required for the Windows 10 Migration Project.  They can be named anything but, we will stick with a standard.  The sites that need to be created are: W10 – Evaluation and W10  – PostImage.  Two Groups also need to be created to drive endpoints into the sites.

W10 – Evaluation – All analysis and fixlets to gather information on whether an endpoint can physically make the conversion to Windows 10.

Computer Subscriptions: ALL Computers

Custom Analysis

Hardware Information – Gathers information on Dell Hardware (BIOS Updates, Dell Software Updates, and Dell Available Updates) This uses an API that must be generated via the customer.

BIOS & Hardware Information – Gather various BIOS information on Hardware Endpoints, some BIOS may need to be updated to properly support UEFI.

Windows 10 – Compatibility / Desired State – This analysis reports on Windows 10 Bare Metal Install Compatibility. Can also be used for Upgrade status as well.

Windows 10 Adoption: User Profiles on Endpoint – Before we migrate the Endpoints to Windows10, if not using an impact upgrade, we need to save off the user state. The user state will then be capture on a Network Share to be restored to the endpoint AFTER the Windows10 system is installed. Given the size of various user states, this could be time consuming and resource intensive. This Analysis lets you understand that amount of user profiles and sizes in your environment. It is recommended to review and clean up user profiles over a certain size.

Warranty Data – Hardware – Warranty data for hardware analysis brings back the Start Date, End Date and the amount of days left (+/-) for the hardware warranty on the endpoint.

Fixlets

Supported Win10 Models – (Needs to file created under wwwrootbes\W10 update via Fixlet in Master Site) – Customized updating for Supported Models to move to Windows10. Each company can create an “Unsupported” list of hardware models that they feel are not capable of running windows10 in their environment. Some customers, even though Windows10 works on a model, may feel that until the VENDOR creates drivers and officially supports windows10 on specific hardware do not wish to move to windows10 on such models. This task can be run to set a flag on each client setting “WIN10MODELSUPPORT” to be either True or False. Hence leveraging this information in reports and workflows for the windows10 Adoption.

Track Primary User – This task will become relevant and execute an action script to set the following client settings, which are then analyzed by the Primary User property to determine which user has logged in the most over the past 10 logins.  This information is stored in the following client settings.  If these client settings do not exist on the client, then the task/policy will fail.

If these client settings do not exist on the client, then the task/policy will fail.

In Place or Wipe – This Task is set to run as a policy on all Endpoints in the Adoption Site, it is will run once a day to determine if an endpoint can be a target for In-Place upgrade, or needs to be PXE booted and re-imaged. To be considered “In-Place” upgradeable, the endpoint must be running Win7/8/8.1 and have UEFI enabled and running a 64bit version of Windows. Note: devices that have completed the migration with a W10STATUS=COMPLETE are not relevant for this Fixlet

BitLocker – Encryption Status – Optional – This task uses the native BitLocker Encryption command line tools to check the status of the all drives. This analysis also reports on the TPM module.

Warranty – Optional – Gather Warranty information for Dell, Lenovo, HP vendors.

Baselines

W10 Evaluations – This baseline is designed to run on all windows-based endpoints (non-servers) to check for the migration status of moving to windows 10. The actions performed in this baseline are mostly designed to help determine the compatibility of devices to support windows 10 operating system. Other aspects of the baseline can be used after the migration to windows 10 such as collecting warranty information.

W10  – PostImage – Automation to process configuration, software installations, domain join etc.  This will be after the Windows 10 Base image is installed.  Computer Subscription Relevance:   Is a member of W10_POST

Analysis

None

Fixlets

W10 Client Setting: CPU Usage HIGH – The BES Client is designed to use only a small fraction of the computer’s CPU (< 1-2%) on average. This fixlet is used in the workflow of Windows10, because the endpoint is not yet production (no user) and we wish the process to run as fast as possible, so we set the CPU usage for BigFix to be high.

ScreenLock Install and Run Screen Blocker – W10 – Pulls down the Champion Screen Saver/Lock. This will lock the screen, disabling Ctrl-Alt-Del and update the monitor with the status of the POST workflow. To exit the screen lock run the Fixlet “ScreenLock – EXIT”. This action will also create a link in the Startup Folder for all users to auto launch the Screen Lock upon login.

WIn10 Auto login Feature – ON – During the windows 10 adoption for newly imaged endpoint, we set the Admin auto login feature so we can set the screen saver and keep others from logging until we are done.

ScreenLock – Base Software – Changes the working on the endpoint device that is running the screen lock program, Default verbiage is “Installing Base Software now…”

W10STATUS – BASE SOFTWARE 2 OPTIONAL SOFTWARE – Use to move the endpoint thru the automation baselines, this fixlet was designed to work under the automation of the Windows 10 POST migration site, appearing at the end of the baselines to move the endpoint to the next applicable baseline by changing the W10STATUS client setting

ScreenLock – Optional Software – Changes the working on the endpoint device that is running the screen lock program, Default verbiage is “Installing Optional Software now…”

W10STATUS – OPTIONAL SOFTWRE 2 JOIN DOMAIN – Use to move the endpoint thru the automation baselines, the fixlet was designed to work under the automation of the Windows 10 POST migration site, appearing at the end of the baselines to move the endpoint to the next applicable baseline by changing the W10STATUS client setting.

ScreenLock – Join Domain – Changes the working on the endpoint device that is running the screen lock program, Default verbiage is “Joining the AD Domain…”

Change Computer Name – Windows – This newer version uses WMI to change the computer name of a NON domain device. A REBOOT will occur after running this action.  Default action for workflow is to change the computer name to the OLD hostname based on the inventory file

W10 JoinDomain – This Fixlet uses a VBS script to join the domain (edit the script) using the same domain account used for Capture / Restore User State. The default action will use the Inventory.txt file from the post workflow to determine the new hostname and OU the endpoint belongs to.  Action 2 will change a computer that is in a domain to a new hostname.

W10STATUS – JOIN DOMAIN 2 USER STATE – Use to move the endpoint thru the automation baselines, this fixlet was designed to work under the automation of the Windows 10 POST migration site, appearing at the end of the baselines to move the endpoint to the next applicable baseline by changing the W10STATUS client setting.

ScreenLock – UserState Restore – Changes the working on the endpoint device that is running the screen lock program, Default verbiage is “UserState Restore…”

W10 – Restore User State (INPLACE) – This process uses the reverse of the capture Fixlet in the pre site. Using the _UNCPATH of the client and the serial number of the device or the OLD computer name from the c:\windows\inventory.txt file, which gets download from the Fixlet “(P1) – Fetch Inventory” in the Stage 1 baseline. Both options are available, so you need to RESTORE that same way your CAPTURED the profiles.

W10STATUS – USER STATE 2 FINAL – Use to move the endpoint thru the automation baselines, this fixlet was designed to work under the automation of the Windows 10 POST migration site, appearing at the end of the baselines to move the endpoint to the next applicable baseline by changing the W10STATUS client setting

ScreenLock – Final Stage – Changes the working on the endpoint device that is running the screen lock program, Default verbiage is “Final Stage in Progress.”

W10 Client Setting: CPU Usage Normal – The BES Client is designed to use only a small fraction of the computer’s CPU (< 1-2%) on average. This fixlet is used in the workflow of Windows10, at th4e end of the workflow to set the CPU usage back to normal.

WIn10 Auto login Feature – OFF – During the windows 10 adoption for newly imaged endpoint, we set the Admin autologin feature so we can set the screen saver and keep others from logging until we are done.

ScreenLock – EXIT – Exist out of the Champion Screen LOCK program, which gives control back to the keyboard on the endpoint. The default action will stop the screen saver, remove the link in stat-up and delete the entries folder c:\CSG-SSaver. The second action will simply place “EXIT” into the data_Files.txt to stop the binary from running but will keep the binaries and link in the start-up programs.

W10STATUS – FINAL 2 COMPLETE – Use to move the endpoint thru the automation baselines, this fixlet was designed to work under the automation of the Windows 10 POST migration site, appearing at the end of the baselines to move the endpoint to the next applicable baseline by changing the W10STATUS client setting.

Baselines

Stage 1 Post Configuration – Baseline #1 in the default workflow. This baseline be default contains the pre-configuration steps to prepare the endpoint to move thru the workflow, however additional items can be added in this baseline. the last entry should always be the Fixlet W10STATUS-XXXX that will move the device to the next baseline in the automation workflow.

Stage 2 – BaseSoftware – Baseline #2 in the default workflow. This baseline be default, should contain all the software packages that each endpoint should sav installed after imaging to Windows 10. The last entry should always be the Fixlet W10STATUS-XXXX that will move the device to the next baseline in the automation workflow.

Stage 3 – Optional Software – Baseline #3 in the default workflow. This baseline be default, should contain all of the optional software packages that each endpoint should sav installed after imaging to Windows 10..The optional software packages should have an added relevance statement that checks for an entry in the inventory.txt file (pulled down in the post Configuration Stage) that has the name of the software package making it relevant because the software was installed prior to re-imaging the endpoint.

Stage 4 – JOIN DOMAIN – Baseline #4 in the default workflow. This baseline be default, is where the automation process joins the endpoint back into the AD domain. Some workflows may determine to join the endpoint to the domain during the imaging process, if that is the case, then this baseline can simply move the endpoint along in the workflow.

Stage 5 – User State Restore – Baseline #5 in the default workflow. This baseline be default, is where we restore the userstate of the device after it has been imaged, software has been installed and the endpoint is back into the AD domain. The default workflow here also uses the UNCPATH client setting to determine where to restore the UserState from.

Stage 6 – Final Stage – Baseline #5 in the default workflow. This baseline be default contains the cleanup actions such as: setting CPU to normal, setting W10STATUS to complete, and remove screen lock.

1. Bare Metal Server Setup – Setting up the server to enable serving out images over the network. This includes PXE setup, MDT bundle creation, images, and profile management, and configuration. Determine your version.Open the BigFix Console.  Click Help in the toolbar then select About IBM BigFix Console. For this, we will be using version 9.5.11 Relay.

2. Install the Relay – Run FixletID 3760 Installs the IBM BigFix Relay 9.5.11 on the selected Windows computers. From the BES Support site on the endpoint you would like to make the relay.

3. Install OSD Bare-Metal Server via the Dashboard. Navigate to Systems Lifecycle Module -> OS Deployment and Bare Metal Imaging -> Manage Bare Metal Servers -> Server Management. Click Install -> Acknowledge the license agreement-> Define Installation options -> Enter Credentials -> Select the relay you’d like to deploy OSD to. This will install PXE server on that relay and it could conflict with any other PXE server on that subnet.

4. Setup the MDT Bundle. Bigfix utilizes the Microsoft Deployment Toolkit to migrate an endpoint to Windows 10. The custom content needs to be added to the BigFix MDT bundle for the WinPE environment (to allow for UEFI switching) this is accomplished by placing “c:\customContent” on the MDT Bundle box, and adjusting the Parameters.ini file to include the content.On the MDTBUNDLE machine we are using to create the bundles, the file structure looks like below.<- BigFixOSD is the output of our Bundle creation
   <- Custom Content, where we have the custom script for UEFI switch
   <- MDT bundle creator kit, where we run the Create Bundle and the parameters.ini file.

   Inside the C:\OSDSETUP\MDTBundleCreator directory run in admin DOS prompt, or right click and run as Admin“MDTBundleCreator64.exe”.

5. Once complete, upload our newly built bundle BigFix.<- Inside the Bare Metal Site
   <- click the Bundle and Media Manager
   
6. Upload the MDT Bundle in this panel. If you are making changes to the UEFI scripts, make sure you Overwrite the Pre-Installation Environment. Give the Bundle a Name that makes sense to your organizations. If you need to change the Image to use the New Bundle, Select the WIM image, which highlights the Profiles based off this WIM image, here you can click the Pencil icon to edit the profile and change the MDT bundle it uses.
   
7. Inventory Setup – To determine the software on an endpoint pre-migration, Web Reports will be used to determine what is installed on a particular endpoint. Windows 10 migration requires to have information about windows endpoints when running the WIPE/INPLACE workflow.Computer Name, Installed Software and Serial Number are required for the workflow.
   Run the BAT file with the argument <reportfile>
   Batch File Entry Example Insert the batch file on the bigfix server at: Program Files (x86)\BigFix Enterprise\BES Server\BESReportData\CustomExe
   copy %1 “D:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\OSD\win10.txt”
   del “D:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\OSD\win10.zip”
   “c:\Program Files\7-zip\7z.exe” a -tzip “D:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\OSD\win10.zip” “D:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\OSD\win10.txt”
8. Windows 10 Status – The following are the VALID values for the client setting “W10STATUS” variable on our endpoints. This setting is used to report and control the workflow of the Windows10 adoption. These values are listed below with the explanation of which each means

• EXCEPTION: This HALTS the workflow for any automated workflow, exception could be a highly sensitive endpoint such as a CEO endpoint (which we can do via file or OU).
• COMPATIBLE: The overall hardware of the endpoint is capable of supporting windows10, initially based of Microsoft recommendations. This can however be modified to meet any Customer requirements, such as higher level of memory

–   INPLACE: when an endpoint is hardware capable of running windows10, we then set the ability the tells us if the endpoint can perform in “In-place” upgrade (is 64bit/UEFI enabled/Disk space) it can do a faster more to Windows10 without wiping the hard disk.

–   WIPE: A compatible hardware endpoint that needs to have the hard drive wiped. This would be because we need to move from 32-bit OS to 64Bit, or switch from BIOS to UEFI.

• CAPTURING: This status will change when BigFix starts to CAPTURE the user settings on an Endpoint. This may take time depending on the User Profile Size. This can be used for reporting and control the work flow
• CAPTURED: This is flagged once the User Profile was successfully capture.
• PXE: This setting will be set on the OLD machine (that will have its hardware save but re-imaged) when a Force Network Boot happens. This lets us know this endpoint should grey out and NOT come back alive in Bigfix, but a duplicate computer name will appear once the workflow is complete.
• BASE SOFTWARE: This setting report that the Endpoint has completed its windows10 install and is now pushing the BASE software that all endpoint will have, this as well controls the workflow
• ADDITIONAL SOFTWARE: The setting reports that the endpoint is now pushing down software to the newly imaged endpoint that it has previously (can move from 32—64 or newer versions) has installed. This controls the workflow.
• USER STATE RESTORE: The status of the endpoint is now RESTORING the user state before we did the migration. This can take time depending on the size of the user state. This as well controls the workflow.
• FINAL This status reports that we are changing the name of the endpoint and adding back to the DOMAIN
• COMPLETE: Our process has completed.

Same workflows above, but adds prefix “LIFECYCLE” to the tags:

• LIFECYCLE: denotes an endpoint going thru the LIFECYLCE workflow
• LIFECYCLE-BASESOFTEWARE: Same as BASESOFTWARE, but for LIFECYCLE
• LIFECYCLE-ADDITIONALSOFTEWARE: Same as Additional Software, but for LIFECYCLE
• LIFECYCLE-USERRESTORE: Same as User restore, but for LIFECYCLE

For more information call 877 788 1617 or email [email protected]