Integrate the Splunk Forwarder Agent with an Omnissa Horizon VDI Image

Introduction

Splunk is a great tool and very useful for establishing any security issues in your environment.  It allows you to search, analyse and visualise data in real time.  It is a good fit for security sensitive environments, and this includes your VDI infrastructure.  In this blog I show you how to integrate the Splunk forwarder into your Omnissa Horizon Gold image (sometimes called the reference image), and in such a way that your cloned instances will also have their own unique data inputs into the Splunk repository.  The process consists of the following steps.

1) Install the Splunk Forwarder application.

2) Generalize the Splunk Agent.

3) Create the Synchronisation scripts.

4) Run the Optimization Tool and create the snapshot.

5) Create the Horizon Desktop Pool with the a Post-Synchronization Script.

The implementation steps in this blog have been tested on Splunk version 9.4.1 and Omnissa Horizon version 8.12.x

Install the Splunk Forwarder application.

Follow your standard OS installation process for creating a gold image, which should include installing the Horizon Agent.  When you are satisfied with your gold image, install the Splunk Universal Forwarding agent - again the wizard details will be specific to your environment.

When completed, wait for the Splunk application definitions to download - these will appear in <installation folder>\SplunkUniversalForwarder\etc\apps - by default this will be C:\Program Files\SplunkUniversalForwarder\etc\apps.  

For the purposes of this blog we are assuming you have installed the Splunk forwarding agent to the default directory.

There should be more than 8 subfolders indicating the apps download has completed.

When the app download has completed, delete the following file: "C:\Program Files\SplunkUniversalForwarder\etc\system\local\deploymentclient.conf"

Generalize the Splunk Agent

In this step we remove the properties specific to the Gold reference installation that are in the Splunk forwarder configuration files  - for instance the host name.

1) Open a command prompt as administrator and navigate to the bin directory - for instance C:\Program Files\SplunkUniversalForwarder\bin

Run the following command: splunk.exe clone-prep-clear-config

The next step is to verify that the cloneprep file appears in the SplunkUniversalForwarder directory

Create the Synchronization scripts

The synchronization scripts will execute a command to repopulate the configuration files with the cloned VM's details so that duplicated entries are not passed into the Splunk repository.  Manually this is achieved by running splunk.exe restart, however we need to create scripts to achieve this during the Horizon pool creation process.

1) Create a local directory on the VDI gold image - for instance c:\Scripts.

2) create a batch file in this directory - in this example we will call it begin.bat.  In this file enter in the following command:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -file c:\scripts\modify.ps1

3) In the Scripts directory create another script file called modify.ps1.  Populate this file with the following PowerShell command: 

start-process -NoNewWindow -Filepath "c:\program files\SplunkUniversalForwarder\bin\splunk.exe" -ArgumentList 'restart' -Wait

Note: you can test this by running begin.bat, but you will have to once more run the splunk.exe clone-prep-clear-config command to recreate the cloneprep file and generalize the Splunk installation.

Run the Optimization Tool and create the snapshot

As you would normally do, run the Optimization tool.  My process includes running the following in order: Analyze, Optimize, Generalize and then Finalize.  

Ensure the VM Gold build is switched off and then create a snapshot.  The snapshot is used, of course, when running the Desktop Pool Creation wizard.

Create the Horizon Desktop Pool with the a Post-Synchronization Script

In your Horizon Admin portal create an Instant Clone pool (ClonePrep) using the new Gold image and snapshot.  When getting to part 10 of the wizard, the Guest Customization window - enter in c:\Scripts\begin.bat in the Post-Synchronization Script name box.

After your pool is created, open a VDI instance with the Horizon client.  Ensure that the cloneprep file does not exist in C:\Program Files\SplunkUniversalForwarder.  Once confirmed you can also check entries exist in the Splunk repository for your cloned instance.

Conclusion

I hope you have enjoyed reading this little blog.  The VDI Horizon platform is great for spinning up multiple VM clones.  The Splunk Enterprise reporting solution is a great way of maintaining the integrity of your physical infrastructure, and using the above procedure - it is also a great way of observing any issues arising in your VDI Horizon platform.

HP Device Manager - updating components without internet access

Introduction

A good reason for using a VDI solution with the use of the HP ThinPro thin client devices is security.  The devices are highly secure - the ThinPro OS provides layers of security with signed OS components and a read only and encrypted file system.  And oftentimes, for this reason, they will be located in air-gapped highly secure environments.  HP Device Manager (HPDM) is used to manage these systems and HPDM does not require internet connectivity.  Thus the solution is a very good fit for environments that are sealed off from external threats.  HPDM does require updating from time to time.  When a new version of HPDM is released, all vulnerabilities address by the new release are resolved when the upgrader/installer file is executed on the offline installation of HPDM.  

In-between patches and updates, that is, updates to various components of HPDM, such as OpenSSL for instance - these are normally installed through the HPDM Configuration Center.  The administrator can click on the HPDM HTTPS Repository, click on Check for Updates, and then click on Download if updates are available.

The Problem

This updating solution is only suitable for HPDM installations on servers that have internet access.  Where there is no internet access, the Check for Update action will fail and the status will be Update Check Failed.

The Workaround

Such fixes and updates can be downloaded from an internet facing device and imported into the offline instance of HPDM.  Here is the process:

1) On the internet facing device, open a browser and go to https://ftp.hp.com/pub/hpdm/dmcatalog.xml.  Save this page locally as dmcatalog.xml.

2) Search the dmcatalog.xml file for .zip entries and download each of them by navigating to https://ftp.hp.com/pub/hpdm/Patches/HTTPS_Updates/<name of zip file>  For example:

https://ftp.hp.com/pub/hpdm/Patches/HTTPS_Updates/OpenSSL.zip

At the time of writing the dmcatalog.xml file contains the following .zip entries

Apache.zip

OpenSSL.zip

PHP.zip

These three files can be downloaded from the following URLs.

https://ftp.hp.com/pub/hpdm/Patches/HTTPS_Updates/OpenSSL.zip

https://ftp.hp.com/pub/hpdm/Patches/HTTPS_Updates/PHP.zip

https://ftp.hp.com/pub/hpdm/Patches/HTTPS_Updates/Apache.zip

Note: The name of the .zip file is case sensitive.  

3) Copy your downloaded files and the dmcatalog.xml file to a USB key and copy into the configuration center directory on your air-gapped HPDM server.  In this case I copy the files into c:\Program Files\HP\HP Device Manager\Configuration Center

4) Open a command prompt as Administrator and navigate to the Configuration Center directory, containing the updates and the dmcontrol.xml file.

5) Run the following command:  HTTPSUpgrade.exe -l  (as in lima)

Conclusion

As can be seen from the screen grab, all three components have been upgraded on a HPDM installation.  Further, this installation of HPDM does not have internet connectivity - thus the above process is ideal for highly secure, air-gapped environments.

I hope you have enjoyed this little blog, and I wish you much success in your own updating requirements.

WSUS - Reset Server Node issue

Introduction

My existing client relies heavily on WSUS for their patching purposes.  The is indeed a mature and tested solution but it does contain its own peculiar issues.  One of these is the Reset Server Node error message that appears when using the Updates Services administration console.  Oftentimes we want to know if the last synchronization completed successfully - and it is here where I am seeing the issue appear most times.  The administrator opens the console and navigates to Update Services\<Server>\Synchronizations. The Loading synchronization history percentage number will increase and stick at a random number.  After a couple of minutes an Error:Connection Error message appears with the options of Reset Server Node or Copy Error to Clipboard.  Getting beyond this stopper can be tricky and so in this blog I will list the fixes that have worked for me.

Note:  I have seen this error in installations of WSUS using the Windows Internal Database (WID).  The following fixes have been tested on installations using WID.

Fix 1: Run the clean-up Wizard.

This fix is straightforward.  Open the Updates Services Admin console and navigate to Options in the left hand side pane.  Select the Server Cleanup Wizard in the right hand side pane.  Ensure all options in the Server Cleanup Wizard are selected and click on Next and Finish to complete the wizard.

Fix 2: Increase Memory and CPU

This fix is convenient to implement on virtual machines.  If it is a VMWare VM then you can power down the VM and select Edit Settings in vSphere.  In our environments we have found that a configuration of 8 CPU and 16 GB of memory can resolve the issue.

Fix 3:  Reindex the WSUS database

On your WSUS server create a directory such as d:\WSUSMaintenance.  Copy the SQL script into this directory - naming it appropriately. In this example I name it WSUSDBMaintenance.sql.  The script can be found at:

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/reindex-the-wsus-database  

The next step is to install the sqlcmd.exe utility.  This can be downloaded from:

Release v1.8.2 · microsoft/go-sqlcmd · GitHub

After downloading and installing the appropriate sqlcmd msi file, open a command prompt as an administrator and run the following command from the sqlcmd.exe location (usually c:\program files\sqlcmd\)

sqlcmd -I -S \\.\pipe\MICROSOFT##WID\tsql\query -i <path to sql file>\wsusdbmaintenance.sql 

For example: sqlcmd -I -S \\.\pipe\MICROSOFT##WID\tsql\query -i d:\wsusmaintenance\wsusdbmaintenance.sql  

There may be some error messages and these can be ignored.

Fix 4: Modify the WSUSPool Application Pool

In IIS admin navigate to Application Pools.  Right click on the WsusPool application pool and select Advanced Settings.

Modify the following values accordingly

Queue Length - 2000

Idle Time Out - 0

Ping Enabled - False

Private Memory Limit - 0

Regular Time Interval - 0

Fix 5: Clean up WSUS using Powershell.

Open a command prompt with administrator permissions and run powershell.exe -executionpolicy unrestricted

Enter in the following command:

Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates

Fix 6: Reinstall WSUS after removing the WID database.

CAUTION: The following steps assume you have a procedure/document to install WSUS from scratch.  This fix shows you how to remove WSUS and the Windows Internal Database cleanly to address the Reset Server Node issue.

If none of the above is successful you may have to resort to a WSUS reinstall.  Keep in mind that simply removing the WSUS role and reinstalling the role may not, by itself, resolve the issue.  To be sure you should also remove the Windows Internal Database (WID) as well.  This is how I managed this task.

1) Open Server Manager and click on Local Server on the left hand side.

2) In the right hand pane navigate down to Roles and Features.  

3) Select Remove Roles and Features from the Tasks option.

4) The Before you Begin window appears.  Click on Next.

5) The Server Selection window appears.  Click on Next.

6) The Server Roles window appears.  Deselect the Windows Server Update Services feature.

7) The Remove features that require Windows Server Updates Services window appears.  Click on Remove Features. Continue clicking on Next to complete the wizard. 

8) Restart Server if required.

Having removed the WSUS role you can now remove the WSUS WID database.

1) In Explorer navigate to c:\windows\WID\Data.

2) Delete the SUSDB.mdf and the SUSDB_log.ldf files.

3) Open Server Manager and click on Local Server on the left hand side.

4) In the right hand pane navigate down to Roles and Features.  

5) Select Remove Roles and Features from the Tasks option.

6) The Before you Begin window appears.  Click on Next.

7) The Server Selection window appears.  Click on Next.

8) The Server Roles Window appears. Click on Next.

9) The Remove Features window appears.  Deselect Windows Internal Database.

10) The Remove features that require Windows Internal Database window appears.  Click on remove Features.  Continue clicking on Next to complete the wizard.

11) Restart the server if required.

The next step would be to delete the WSUS content.  If you specified c:\WSUS as your content folder, that is, the directory where updates are downloaded when synchronizing - delete the files in this directory.  You can then reinstall WSUS following your installation procedures.

Conclusion

The Reset Server Node error prompt is annoying and quite common as well.  I do hope one of the fixes in this blog has resolved your issue.  I thank you for reading this little blog and wish you successful patching in your environment.

ConfigMgr Setup and the SQL RMO error

Introduction

My test rig was in need of a rebuild and being somewhat adventurous I decided to build it with Windows Server 2025 (Eval) and the technical preview ConfigMgr version 2411.  I did install the usual prerequisites such as WAIK, SQL 2022, SSMS, WinPe etc.  I proceeded to run the ConfigMgr setup and received the following error immediately: Error: Setup missing critical SQL prerequisite.  Install the latest Microsoft ODBC driver for SQL.

I did therefore install version 18 (x64) of this driver from the following location:

Download ODBC Driver for SQL Server - ODBC Driver for SQL Server | Microsoft Learn

After starting the ConfigMgr setup again, and passing the prerequisite checker, I was then faced with another error: Setup could not install SQL RMO

The Fix

I clicked on View Log and discovered the failure was on the installation of msoledbsql.msi.  This file gets downloaded as part of the Prerequisites Download page of the installation wizard.

So I then tried installing this file by double clicking on it - this then provided more information about the issue. The failure is occurring because it is trying to install ODBC driver version 18 but I had already installed this version. 

I then went into Control Panel\Programs and Features and removed the existing versions of  Microsoft ODBC driver for SQL Server.  I rebooted the server and then installed version 17 of the ODBC driver for SQL Server.  I only installed the x64 installer of version 17 - this can be found a bit further down the downloads page at:

Download ODBC Driver for SQL Server - ODBC Driver for SQL Server | Microsoft Learn

Once more I tried to manually install the version of msoledbsql.msi from the prerequisites download source and received a further error: This application requires Microsoft Visual C++ Redistributable for Visual Studio 2022.....

I then downloaded and installed both x86 and x64 versions of the Microsoft Visual C++ Redistributable for Visual Studio 2022 from the following location.

Latest supported Visual C++ Redistributable downloads | Microsoft Learn

I was then able to complete the installation of Configuration Manager Technical Preview 2411 on my Windows Server 2025 Eval installation.

Conclusion

Sometimes we are thrown a curve ball and it can take some deep digging to resolve the issue.  To avoid this particular issue you can do the following, before running the ConfigMgr setup wizard.

1) Uninstall existing versions of the Microsoft ODBC driver for SQL

2) Install Microsoft ODBC driver for SQL version 17 (not 18)

3) Install Microsoft Visual C++ Redistributable for Visual Studio 2022 (x86 version)

4) Install Microsoft Visual C++ Redistributable for Visual Studio 2022 (x64 version)

5) Reboot server.

6) Run the ConfigMgr setup wizard.

I hope you have enjoyed this little blog and I wish you similar success in your own installation of the latest version of Configuration Manager.

Tattoo Task Sequence Data in WMI

Introduction

In the OS provisioning build world we do like to stamp a newly built device with some information.  This may be the task sequence name and the build version as well as other useful information.  And it is common to place this information in the registry and collect it with MECM by extending the hardware inventory collection data.  With my latest project I decided to write this information to the WMI repository using a PowerShell script.  One advantage of branding in this way is that extending the Hardware Inventory is much easier. 

In addition, I decided to include data that would be useful for troubleshooting issues.  For instance, by including the models supported by the task sequence, a helpdesk technician can easily determine if an incorrect Task Sequence had been deployed to the device when viewing the data in the Resource Explorer in MECM.

There are three steps required to complete this task

1) Populate the PowerShell script with the data to be collected.

2) Create a Task Sequence step to run the PowerShell script.

3) Extend the MECM hardware inventory classes to collect this information from the provisioned device.

Populate the PowerShell script with the data to be collected

The first part of the PowerShell script is the VARIABLE DECLARATION section.  Fill it in as required.  The $WMIClassName variable defines the name of the class under which the instance, containing the data, will be created.  This name should remain the same whenever you update the build task sequence.

#VARIABLE DECLARATION

$WMIClassName="BuildInfo"

$BuildVersion="1.0"

$ProjectName="ENHANCEMENT"

$TSName="Install Windows 10 22H2"

$SupportedModels="HP Pro SFF 400 G9,Lifebook u7410"

$ChangesMade="Removed Internet Explorer.  Added drivers for HP Pr SFF 400 G9.  Removed Windows Store App"

The second part of the script creates the WMI class.  The third part of the script deletes any instances under the class name, if they exist, and then creates the instance with the information as defined in the VARIABLE DECLARATION section.  Here is the script complete with the above information defined.

#VARIABLE DECLARATION

$WMIClassName="BuildInfo"

$BuildVersion="1.0"

$ProjectName="ENHANCEMENT"

$TSName="Install Windows 10 22H2"

$SupportedModels="HP Pro SFF 400 G9,Lifebook u7410"

$ChangesMade="Removed Internet Explorer.  Added drivers for HP Pr SFF 400 G9.  Removed Windows Store App"

#CREATE THE WMI CLASS

$newClass = New-Object System.Management.ManagementClass("root\cimv2", [String]::Empty, $null); 

$newClass["__CLASS"] = $WMIClassName; 

$newClass.Qualifiers.Add("Static", $true)

$newClass.Properties.Add("BuildVersion",[System.Management.CimType]::String, $false)

$newClass.Properties["BuildVersion"].Qualifiers.Add("Key", $true)

$newClass.Properties.Add("ProjectName",[System.Management.CimType]::String, $false)

$newClass.Properties.Add("TSName",[System.Management.CimType]::String, $false)

$newClass.Properties.Add("SupportedModels",[System.Management.CimType]::String, $false)

$newClass.Properties.Add("ChangesMade",[System.Management.CimType]::String, $false)

$newClass.Properties.Add("InvalidExtensions",[System.Management.CimType]::String, $false)

#$newClass.Properties["InvalidExtensions"].Qualifiers.Add("Values",$true)

$newClass.Put()

#REMOVE EXISTING INSTANCES

$Inst=get-wmiobject -query "select * from $WMIClassName"

$Inst|remove-wmiobject

#CREATE THE NEW INSTANCE

set-wmiinstance -Class $WMIClassName -Arguments @{BuildVersion="$BuildVersion";ProjectName="$ProjectName";TSName="$TSName";SupportedModels="$SupportedModels";ChangesMade="$ChangesMade"}

This script should be tested on a device to ensure the class is created and the instance is populated.  Test it on a device that also has the MECM console installed.

After the script is run, type in wbemtest.  Click on Connect and then Connect again.  Click on Query and type select * from <name of class>.  In this case it would be select * from BuildInfo.

Click on Apply and then double click on the BuildInfo.BuildVersion instance.  Ensure that all the data is filled in as expected.

Create a Task Sequence step to run the PowerShell script

Open the MECM console and navigate to Software Library\Overview\Operating Systems\Task sequences.

Right Click on your task sequence and click Edit.  Click on a step after the Setup Windows and Configuration Manager step in the Setup Operating System group.  From the top click on Add and then General and then Run PowerShell Script.  Enter in a name such as Create Build Tattoo.  Click on the Enter a PowerShell script option and then select Add Script .  Paste the script into the script area.

Click on Ok.  Ensure that the correct PowerShell execution policy level is selected and then click on OK again.

Extend the MECM hardware inventory classes

Firstly, as suggested above, you should run the script on a device with the MECM console installed.  This will create your WMI class along with an instance containing the data.  This data will be reported back to the MECM database when the Hardware Inventory cycle completes on your device.

Open the MECM console and navigate to  Administration\Overview\Client Settings.  Right click and select Properties on the required Client Settings object in the right hand pane.  In this example we use the Default Client Settings object.

The Client Settings window appears.  Highlight the Hardware Inventory setting.

Click on Set Classes.  The Hardware Inventory Classes window appears.

Click on Add and then Connect and then Connect again.  The Add Hardware Inventory Classes window appears.  Locate your newly created class and select your newly created class.  Click on OK

The Hardware Inventory Classes window reappears.  Select your newly created class and deselect the Invalid Extensions property.

Click on OK and then OK again.

You can now use Resource Explorer, within MECM, to view the build details pertaining to the device. This will appear after the next hardware inventory cycle completes on your clients.

Conclusion

The build tattoo is often overlooked but is really essential.  It is vital for ensuring that you can bring all your built devices to the same level.  If support orientated data is included, such as supported models, it can be of great assistance to the helpdesk.  I hope you have enjoyed reading this article and I wish you every success in developing your own build versioning tattoo in your environment.

Deploy Windows 11 with MDT - Supported

 Introduction

The Microsoft Deployment Toolkit (MDT)  has been used by many companies for the provisioning of operating systems.  It does have a mature and powerful task sequencing engine.  And while not really scalable to enterprise level environments, and being a firmly lite touch rather than a zero touch solution - it does have one major benefit.  It is free.

Many thousands, if not millions of Windows operating systems will have been provisioned in build rooms throughout the world using MDT.  Unfortunately the last client OS to be supported was Windows 10.  Windows 11 is not supported, and in fact you cannot import the Windows 11 Operating system into the Deployment Share.  Nevertheless Windows 11 can be deployed using MDT and in such a way as to be fully supported.  Here is how it is done.

1) Create a task sequence to deploy Windows 10, or use your existing MDT Windows 10 task sequence.  Configure the TS with your applications and settings.

2) Configure the TS to copy the Windows 11 source files to a location on the device being built.

3) Create a TS step to configure a Scheduled Task to run a Windows 10 to Windows 11 upgrade a few minutes after the completion of the Windows 10 Task sequence.

4) Autologon to the device and wait for the Windows 11 upgrade to complete.

The Windows 10 to Windows 11 upgrade is completed after the completion of the Windows 10 task sequence, and because it is started by a task scheduler job, and not MDT; it is a fully supported solution.

This article will cover steps 2,3 and 4.

Copy the Windows 11 Files

You w‎ill need to create a share on your network to contain the Windows 11 source files.  For our purposes we shall call it \\mdtserver\software.

Under this share create a directory called Windows11Files and under this create a directory called Source.  So we have:

\\mdtserver\software\Windows11Files\Source

Copy your Windows 11 source files into this directory.

You will then need to decide on where you will be copying these files on the device itself.  In my case I will be copying these files to c:\support\Windows11.  

Thus I create two task sequence steps to create this path.  The first TS step runs the following command:

cmd.exe /c mkdir c:\support

The second TS step runs the following: 

cmd.exe /c mkdir c:\support\Windows11

The next TS step will need to copy the Windows 11 files to the provisioning device.  The command line I have used to achieve this is as follows:

cmd.exe /c robocopy \\<mdtserver>\software\Windows11Files c:\support\Windows11 /e

Note1:  you may have to select the Run this step as the following account option and then supply an AD account with adequate permissions to access the software share.

Note2: All three of the above task sequence steps are of the type Run Command Line.

Note3: All TS steps detailed in this article should be positioned towards the end of the task sequence, and definitely after the Post Install group.

Create a Scheduled Task to upgrade to Windows 11

Now that we have configured the TS so that the Windows 11 Source files are available locally on the provisioned device, we need to create a Scheduled Task job to perform the upgrade itself.  The script provided here will create a scheduled task to start five minutes after the time the script is executed.  Therefore it should be configured to run as a Run Command Line TS step towards the end of your task sequence so that the task schedular job does not start while the TS is still running.

In this case I call the script win11ug.ps1 and I copy it to the MDT DeploymentShare's script directory, that is: \\<mdtserver>\DeploymentShare$\Scripts.

The Run Command Line TS step contains the following:

powershell.exe -executionpolicy bypass -file "%SCRIPTROOT%\win11ug.ps1"

In addition the Run Command Line step is configured to run under a Domain Admin account.

Here is the script:

#Get ST start time and ensure time format will work with schtasks syntax

$execdate=(get-date).addminutes(5)

$exectime=($execdate).timeofday

$hourchk=[string]$exectime.hours

$minutechk=[string]$exectime.minutes

if ($minutechk.length -lt 2) {

$minute="0"+$minutechk

}

else {

$minute=$minutechk

}

if ($hourchk.length -lt 2) {

$hour="0"+$hourchk

}

else {

$hour=$hourchk

}

$time=$hour+":"+$minute

#Run the schtasks command to create the task schedular job

schtasks /create /tn "Win10Upgrade" /tr "C:\support\windows11\source\setup.exe /Auto Upgrade /EULA accept" /ST $time /RL Highest /ru interactive /sc once

Autologon to the device 

The last Run Command Line TS step is required to run a script that will perform an autologon.  The command line that worked for my scenario was as follows:

Powershell.exe -executionpolicy bypass -noprofile -file "%SCRIPTROOT%\AutoLogon.ps1"

And here is the script itself.  Obviously replace credentials accordingly.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v AutoAdminLogon /d 1 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v DefaultPassword /d <password> /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v DefaultUserName /d <local admin account name> /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_DWORD /v AutoLogonCount /d 1 /f

This script needs to be copied to a file called Autologon.ps1 and then copied to the DeploymentShare's script directory: that is,  \\<mdtserver>\DeploymentShare$\Scripts.

The last step in your TS will be to perform a reboot.  A few minutes after the reboot completes, and after the autologon completes, the upgrade to Windows 11 will commence.

To help you position each of the steps covered in this article, in the correct order, I have included a capture of the steps towards the end of my task sequence. 

Now after your task sequence completes, and within five minutes, the Windows 10 to Windows 11 upgrade will commence and there will be no requirement for any user input.

Conclusion

It might be that your client is not in a position to install an OSD solution that will deploy Windows 11 - in which case this solution may help you. It is a Heath Robinson type workaround to MDT's limitation.  It works well but you will have to decide if an upgrade solution, rather than a pure baremetal to Windows 11 solution, is something your organisation can accept.

I hope you have enjoyed reading this little blog.

Win 11 Let's Connect you to a Network - After OSD Task Sequence completes

Introduction

Recently I put together an MECM task sequence to install Windows 11 Enterprise.  The task sequence would run through and complete all the steps successfully.  After completion the "Let's connect you to a network" window would appear.  The engineer then had to click on "I don't have internet access" and then on "Continue with a Limited setup" in that order, to arrive at the sign in page.  Yes this is only two mouse clicks but I did want to bypass this in an automated way and arrive at the sign in page without this manual input.

The Fix - Part 1

The key to bypassing this "Let's Connect you to a network" screen was to kill the oobenetworkconnectionflow.exe process using the taskkill.exe tool.  If run from a command prompt, the line would be as follows:

taskkill /F /IM oobenetworkconnectionflow.exe

The Problem

Initially I thought that creating a task sequence step to run this command at the end of the Task Sequence would do the trick, however it did not.  This is because the Network Connect page only appeared after the task sequence completed.

My next idea was to run the command as a value for the SMSTSPostAction task sequence variable.  This variable allows you to specify a command to run after the task sequence completes, but before exiting the task sequence - which sounds a bit contradictory.  This approach did not work either - probably because the Network Connect page had not started at the point in time at which the SMSTSPostAction command executed.

The Fix - Part 2

The taskkill command had to be run at a time that I was sure the oobenetworkconnnection.exe 

process was actuated - that is, at a time in which the Let's connect to a network was really displaying on the screen.  This occurred 30-60 seconds after the completion of the task sequence.  Thus I created a PowerShell script that would create a task schedular job to run two minutes after the time the script was run.  The script would be run as the last step in the build task sequence.

This is the PowerShell script:

$execdate=(get-date).addminutes(2)

$exectime=($execdate).timeofday

$hour=[string]$exectime.hours

$minute=[string]$exectime.minutes

$time=$hour+":"+$minute

$sta=new-scheduledtaskaction -execute "taskkill" -argument "/F /IM oobenetworkconnectionflow.exe"

$stt=new-scheduledtasktrigger -once -at $time

register-scheduledtask CancelNetworkFlow -action $sta -trigger $stt -runlevel highest -user "NT AUTHORITY\SYSTEM"

I saved this script as stopncf.ps1

The MECM Package

There are many different ways to run a PowerShell script in MECM - I got this one working by using the good old fashion legacy package.  I then plugged this as a last step in the OSD Windows 11 task sequence as an Install Package step.  The package contained a Program Command Line consisting of the following:

powershell.exe -executionpolicy unrestricted -file stopncf.ps1

The package content consisted of the above PowerShell script called stopncf.ps1.

I have included below the various screenshots of the package settings, in the case that you would like to follow a similar solution.  The package name is StopNWC.

The Task Sequence Step

As already mentioned this package was added as the last step of the Window 11 OSD task sequence.

And here are the details of the sequence step.

C

Conclusion

This issue is normally seen during the task sequence installation itself - but as can be seen it may occur after the task sequence completes.   We can use the solution presented here to remove this unwanted screen, using the task schedular service and a little bit of PowerShell. For those who like to have the entire process automated, I hope you have benefited from this little blog.