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.