Join the HP ThinPro device to Active Directory

Introduction 

Indeed it has been sometime since my last post, and now that I have a little reprieve from my busy work schedule - I thought why not write an article about my favorite subject: the great ThinPro linux based thin client device from HP. In this article I demonstrate how to join your device to a Microsoft Active Directory domain.

Joining the device to Active Directory

You will have to switch your ThinPro device into admin mode.  You can then open the Control Panel by clicking on the bottom left hand Start icon and selecting Control Panel. Click on the Manageability option.

The Active Directory blade is at the top of the list.  Enter in the Domain Name and select the Join the thin client to domain option.  If desired you can expand Advanced options and specify an OU to join - in this case I chose to leave this blank.

Click on Apply.  An information splash appears advising of a system reboot requirement.

Click on OK.  You are prompted to enter in your domain join credentials.

Click on OK.  The domain join process begins.

After about 30 seconds you are presented with a message and a requirement to reboot.

Click on OK to reboot the device.

You can now go into Active Directory Users and Computers and verify that your ThinPro device is now a member of your Active Directory.  In this case the ThinPro has been added to the Computers OU.

The Login experience for an AD joined ThinPro Device.

Now that the ThinPro device is a member of your domain, it does not just load straight into the desktop.  You are now required to enter in your AD credentials at startup.

Conclusion

The ThinPro device is a very secure solution.  Using the AD join feature will add an extra layer of security to your user's experience.  In addition, support staff will now be able to switch the device into Admin mode using an Active Directory administrator account and password, thus a single root administrator password does not need to be disseminated to multiple administrators.  I hope you have enjoyed this little post, and I wish you the same success in joining your ThinPro device to your Active Directory Domain.

Provide HP ThinPro Internet Access using RRAS and NAT

Introduction

In this article I explain how to use Windows RRAS feature to allow your ThinPro device access to the internet.  In this scenario the ThinPro client is managed by HPDM installed on a HyperV Windows Server. The ThinPro device connects to a physical hub and that hub also has a connection to the HyperV host device (my laptop) via a USB ethernet adapter.  The HyperV host has two external virtual switches configured.  One switch provides the HPDM virtual machine with connectivity to this external hub and thus the HP ThinPro connected network.  The other switch provides the HPDM virtual server machine with WIFI access to the internet.  The HPDM server also provides the thin client with an IP address from a 10.10.10.0/24 DHCP scope.  It also provides a DNS service.  Thus we can use RRAS to provide the ThinPro device with access to the internet using NAT.

The Hyper-V Virtual Switches.

My laptop has two network adapters. I have a physical Realtek USB GbE Family Controller adapter and an Intel(R) Wi-Fi 6 AX200 adapter.  In Hyper-V switch manager I created two external switches based on these adapters.

The virtual switch based on the USB Ethernet adapter is called Private Lab Network and provides connectivity from the HPDM virtual machine server to the HP ThinPro physical device via a physical hub. On the server the adapter is called Ethernet 4 and has an IP address of 10.10.10.200

The virtual switch, based on the  Intel(R) Wi-Fi 6 AX200 adapter, is called Internet and provides connectivity to my Internet router.  On the HPDM server the connection is called Ethernet 5 and has an IP address of 192.168.1.235.

The Network Topology

The HP ThinPro physical device gets a 10.10.10.0/24 IP address, DNS and router address from DHCP on the HPDM server.  This gets routed through the physical USB ethernet adaptor.  The HPDM Hyper-V virtual Windows Server machine has a static IP address of 10.10.10.200/24 and thus is on the same same subnet as the physical HP ThinPro Server.  The HPDM server also has an IP address of 192.168.1.235 and thus is also on the same subnet of my Internet Router, whose address is 192.168.1.254.

We can see then that the HPDM virtual machine has access to two networks and therefore we can use it for Network Address Translation (NAT) as configured in the Routing and Remote Access Service feature installed on the HPDM Windows Server.

In summary, for the HP ThinPro network we have:

Detail	Configuration
Network ID	10.10.10.0
DHCP Range	10.10.10.20-10.10.10.40
DHPC Range Subnet Mask	255.255.255.0
Default Gateway	10.10.10.200
DNS Servers	192.168.1.254,10.10.10.200
HPDM Server	10.10.10.200

For the HPDM network we have:

Detail	Configuration
Network IDs	10.10.10.0, 192.168.1.0
DHCP Range	192.168.1.2-192.168.1.253
DHCP Range Subnet Mask	255.255.255.0
Default Gateway	192.168.1.254
DNS Servers	192.168.1.254,10.10.10.200
HPDM Server	10.10.10.200

The Routing and Remote Access Service (RRAS) Configuration.

Note: The following assumes you have already installed the RRAS feature on your HPDM server.

The first step to getting this working is to create two static routes - one for each network adapter on the virtual HPDM Hyper-V machine.

The next step is to Right click on IPv4 and select New Routing Protocol.  Follow the wizard to install the Routing Information Protocol (RIP).  Once this is done right click on RIP and select New Interface.  By doing this you can add both your Internet facing HPDM interface (Ethernet 5 in my case) and your HP ThinPro interface (Ethernet 4 in my case).  Configure the Neighbors properties so that the Use Neighbors in addition to broadcast and multicast option is selected.  Add the Default Gateways of each interface as shown.

Our next task is to add the  HP ThinPro private Interface (in my case Ethernet 4) and the HPDM Internet Interface (in my case Ethernet 5) to the NAT node.  

So for the private HP ThinPro Ethernet 4 network we have:

Private network for HP ThinPro configured as Private

For the HPDM public server network with access to the internet we have:

Public network on HPDM server configured for NAT and as a Public interface

Configure DHPC to deliver both DNS Server Addresses.

Your DHCP scope should be configured so that the HP ThinPro client gets both the internal DNS server address and the Internet Router's DNS address.

Conclusion

Provided you have followed the principles in the blog, your super secure HP ThinPro device should now be receiving internet content to its private network, routed through NAT on your HPDM Hyper-V Windows server.

I hope you have enjoyed this little blog, and I wish you similar success in configuring NAT for your HP ThinPro environment.

The Perplexing 0x80200010 MECM Client Installation Error

Introduction.

Recently a colleague escalated a MECM client issue to me.  The attempted installation of the client, whether done by a manual install command line or via the client push installation method, would not complete.  The following error was found in the ccmsetup.log file

Download Update: A recoverable error has occurred.  A retry attempt will be made. Error: 0x80200010, Description There are currently no active network connections. Background Intelligent Transfer Service (BITS) will try again when an adapter is connected.

The installation did retry but never did complete.  This was happening on a Windows Server 2022 instance, but it has also been reported on Windows 10 and Windows 11 instances.

Killing the Network Location Awareness Service (nlasvc) process worked for Mr Durning.  This fix can be found at:

https://sccmnotes.wordpress.com/2025/08/08/ccmsetup-the-mysterious-case-of-error-0x80200010-there-are-currently-no-active-network-connections/

Providing a Default Gateway address in the NIC's TCP4 properties tab worked for Mr Desai.  This fix can be found at:

https://www.prajwaldesai.com/sccm-client-agent-install-error-0x80200010/

Neither of these fixes worked or were relevant for the case presented to me.  I had to dig a little deeper.

Fix 1 - Install without using BITS.

One workaround was to install the client manually by using the /SOURCE parameter.  With this method the installation will copy the MECM client files locally into the c:\windows\ccmsetup directory without using BITS.  Here are the required steps: 

1) On the machine with the issue create a directory on the c: drive called client. 

2) Copy the MECM client source files into this directory.  The MECM source files can be found in the Microsoft Configuration Manager directory on the primary site - in my installation this is at: C:\Program Files\Microsoft Configuration Manager\Client.

3) On the machine with the issue, open a command prompt with Administrator permissions and navigate to the c:\client directory.

4) Install the MECM client using the /SOURCE switch.  Here is an example of the command line that worked for me:

ccmsetup.exe /SOURCE "c:\client" SMSMP=<FQDN of the Management Point> SMSSITECODE=<site code of the Primary Site.>

For example: ccmsetup.exe /SOURCE "c:\client" SMSMP=SERVER2.TEST.ORG SMSSITECODE=ABC

5)  After pressing Enter your client installation should complete.  

In my example this did complete however the client would not register - and again this appeared to be related to issues with the network connection.  This then led me to fix 2.

Fix 2 - Reset the TCP/IP stack.

Having installed the client by bypassing the BITS download, I was not yet "out of the woods" as they say.  The client did register with the MECM primary site, however the client was not fully activated.  For instance, if I opened the applet by running control smscfgrc from the command line, clicking on Actions - I could only see two actions:  Machine Policy retrieval & Evaluation and User Policy retrieval & Evaluation.  A fully activated client would have at least 10 actions listed, as shown here.

Resetting the TCP/IP stack did resolve this problem.

Note: If you are using a static IP address, your IP settings will be removed.  You will have to reapply them.  It is recommended that you create a local admin account so you can log back into the device in this scenario.

1) Make a note of the device's IP settings.

2) Open a command prompt with administrator permissions.

2) Type netsh winsock reset and press Enter.

3) Type netsh int ip reset and press Enter.

4) Restart your machine.

5) If using static IP settings, log into the machine and reapply your IP configuration.

Conclusion

I hope you have enjoyed this little blog and I hope it has saved you hours of troubleshooting your mysterious 0x80200010 MECM client installation problem.

HP ThinPro 9 - USB Filtering

Introduction

Recently HP released version 9 of the great ThinPro Operating System for their Thin Client devices.  At the time of writing ThinPro 9 is not available for all Thin Client machines - for instance, I was not able to download version 9 for the HP Thin Client T530.  I was able to download the new OS for the the HP T540 device.  One very good new feature for a security strict organization (and all organizations should be security strict) is USB filtering.  We don't want users plugging in USB storage keys, for instance - but we may not want to disable the USB ports in BIOS.  With this new feature we can disable USB keys but allow other USB devices, such as cameras, for instance, to be plugged into the thin client.  Here is how this is done.

Enter Admin mode

You will notice the ThinPro 9 OS has a new and stylish default wallpaper.  You can click on the icon in the bottom left hand corner of the screen to enter Administrator credentials.

Enter in your Administrator's password and click on OK.

Enable USB Filters Whitelisting

Select Control Panel and then click on Hardware and select USB Manager.  Click on the USB Filters tab.  You will notice by default that the USB Filter is off.

Remove Access to USB storage keys

Click the Whitelist option.  Highlight Mass Storage and click on Remove and then Apply.

You will no longer be able to mount a USB key and save data to it. 

Whitelist a USB storage Key

If you do want to allow a specific type of USB key to be used on the thin client you can plug it in and once again (in Admin mode) go to Control Panel\Hardware - click on the USB Manager, select USB Filters\Devices.  You can then select your USB key, click on OK and then Apply.

In this case I will now be able to save data to my Kingston USB drive.

Conclusion

It is always exciting when HP release a new version of the HP ThinPro operating system.  I hope you are impressed as I am with the new USB Filtering feature.  We like to offer our users flexibility and this new features allows this without comprising on security.

HP ThinPro - Upgrade the Omnissa Horizon Client

Introduction

We are able to update the HP ThinPro operating system as new releases become available.  And this will generally result in new software updates as well - Mozilla Firefox, Citrix Workspace, FreeRDP, etc.  Organizations who use the great Horizon View VDI solution will be keen keep the Omnissa Horizon Client as close to the latest release as possible.  This will entail provisioning  releases of the Horizon client that are made available in-between ThinPro OS upgrades.  In this blog I show you how to create a Horizon Client template, and how to deploy it to a client.  I will also show you how to overcome the expired certificate issue that may prevent you from upgrading your ThinPro Thin clients to the latest version of the Horizon View client.

Creating the Horizon View Template

As can be seen - currently my T530 ThinPro Thin client has Horizon View client version 2212 installed.

This version of the Horizon client comes with the HP ThinPro 8.1 sp6 Operating system.  We certainly do want to upgrade this to version 2506 because this newer version contains updated libraries, improved certificate handling, addresses various vulnerabilities, and is generally a more stable version of the Horizon Client.  So how do we achieve this?

Firstly, open up the HPDM console and navigate to the Templates & Rules node and click on HP Update Center.

Filter the results so that the desired version for your OS is listed.

Click on Generate Templates.  The Package Description Editor window appears.  

Click on Generate.  You are prompted to select the appropriate OS.  Click on OK

The Generate Templates window appears informing you that the Template was successfully created.  Click on OK and the Close.

After a few minutes your new Horizon Client template will appear in the Templates & Rules\Templates\All Templates section of the HPDM console.

Deploy the Horizon View Client - version 2506

Navigate to Manage Devices and right click on the Device/s to which you want to deploy the new Horizon client v2506.  

Select Send Task and then select File and Registry in the Category column and then select the omnissa horizon client in the Template column.

Click on Next. The Task Editor window appears.  Click on OK.

The job begins.  You can monitor the update progress in the Task & Reports\Device Tasks section of the HPDM console.  Hopefully the progress bar will turn green, indicating the Horizon client has successfully updated.  If it turns red you can proceed with the following workaround.

Workaround for Signature Block Verification: Expired certificate Error.

Your deployment may have failed with error code 14004022 indicating that the template is using an expired certificate.

If this is the case then navigate to Templates & Rules\Templates\All Templates.  Right click on the new Horizon client template and select Properties.  Select Script and then select Edit.

The Script Sub task window appears.  Enter in -k beside the xarinstall command as shown.

Click on OK and then OK.  You can now redeploy the new Horizon client - confident of a successful upgrade.

Conclusion

Our goal always is to provide the user with a secure and up to date digital experience - and this could not be more true than in the world of VDI.  I hope you have enjoyed this little blog and I hope it has armed you with the know-how so that you can update your ThinPro Horizon client agents to a newer, safer and more stable edition.

Create a MECM Query to get Intune Autopilot Device Import Information

Introduction

Intune Autopilot is a great new cloud provisioning feature.  While not as sophisticated as MECM task sequence based provisioning, it is nevertheless much easier to use and to master.  Of course, before we can provision a device using Autopilot, we are required to import the hardware hash into Intune.  One way to get this hardware hash is to run a PowerShell script.  Another way, if the device is in the MECM database,  is to run a canned MECM report called Windows AutoPilot Device Information.

Yes this report gives you the information, and with an export and some manipulation you can import this into Intune.  Many MECM/SCCM administrators, however, prefer to work with MECM queries instead.  They may not be so confident using the Report builder or native Transact SQL.  Mostly queries are there for the administrators only and they can quickly and easily be created as needed - whether that be to supply a manager with required hardware data, or as the underlining query for a collection.  And so I did create the MECM AutoPilot Hash Query.

Creating the AutoPilot Hash Query

In your MECM console navigate to Monitoring\Overview\Queries.  Right Click and select Create Query.  Provide a name for the Query such as AutoPilot Hash and then click on Edit Query Statement and then click Show Query Language.  Paste the following query into the Query Statement box.

select SMS_G_System_PC_BIOS.SerialNumber, SMS_G_System_COMPUTER_SYSTEM_PRODUCT.IdentifyingNumber, SMS_G_System_MDM_DEVDETAIL_EXT01.DeviceHardwareData from  SMS_R_System inner join SMS_G_System_PC_BIOS on SMS_G_System_PC_BIOS.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_MDM_DEVDETAIL_EXT01 on SMS_G_System_MDM_DEVDETAIL_EXT01.ResourceID = SMS_R_System.ResourceId left join SMS_G_System_COMPUTER_SYSTEM_PRODUCT on SMS_G_System_COMPUTER_SYSTEM_PRODUCT.ResourceId = SMS_R_System.ResourceId

Click on OK.   Click on Next and then Next again and then on Close.  If desired you can also Right Click on the newly created Query and select Properties, and then limit the results to a collection of your choice; or indeed have it configured so that you are prompted for a collection when you run the report - a very useful feature that is not included with the canned Autopilot report discussed earlier.

Creating the Intune Import csv file

Open notepad and copy into it the following line.

Device Serial Number,Windows Product ID,Hardware Hash

Run the AutoPilot Hash query in the MECM console.  Click on CTRL and A to select the results.

Once selected click on CTRL and C to copy the data into the clipboard.  Press CTRL and V to copy the data into the notepad instance you have open.  Ensure that Word wrap is off and complete a replacement of the whitespace with two commas as shown.

You can now save this notepad file as a .csv file.  For instance, AutoPilotImport.csv.

Importing the Autopilot Hash data into Intune.

Sign into your Intune Portal and navigate to Devices\Windows\Enrollment\Windows Autopilot and then Devices.

Click on Import and browse to your Autopilot import file.  Intune will assess the file for any formatting issues.

Click on Import to register the hash data into Intune.

Conclusion

Retrieving the hardware hash data for Intune can be a tricky and time consuming task.  The MECM Autopilot report goes some way to make this easier - and I hope the Query detailed in this report makes the task even easier for you to manage.  I hope you enjoyed this little blog and I with you much success in your Intune Autopiloting importing tasks.