Part 1 of 2: Domain Join via Workspace ONE Tunnel

January 14, 2021   |   by bgarmon

Last Updated June 2, 2021 – Part 4 updated for Tunnel version 2.1.1 release

This is Part 1 of a 2 part guide to configure Workspace ONE UEM’s Domain Join feature in order to allow newly provisioned Windows 10 devices to automatically join Active Directory from any remote network. Part 1 will cover the end-to-end configuration, Part 2 will cover testing and troubleshooting. Part 2 can be found by clicking this link

Components needed to make this work:

  • Active Directory Domain Controller (AD)
  • Access to internal DNS Server
  • Access to public DNS records
  • Workspace ONE UEM Console version 2102 or higher (UEM)
  • Airwatch Cloud Connector (ACC)
  • VMware Unified Access Gateway Appliance (UAG)
  • VMware Tunnel for Windows

Some caveats:

The original version of this blog required manually joining the domain. Now it’s fully automated thanks to the new releases of Workspace ONE UEM 2102. Everything documented below has been tested to function with Workspace ONE UEM Console 2102. Note that VMware is still actively enhancing this feature so I expect to be updating this document several more times over the coming months.

VMware’s official documentation for the Domain Join feature is posted here, but the document in its current version has several steps out of order, it does not include the steps necessary for the AD configuration, it skips the Tunnel Configuration completely, and overall it’s missing the details I find necessary to successfully configure this feature. I’ve reached out to the VMware documentation team to recommend a number of changes and hope a new version will be posted. I include the link in case I don’t get around to editing this blog before a new release changes some critical component leaving you stuck.

To join a domain the device must have line-of-sight to a Domain Controller. What does line-of-sight mean? It means the device must be able to use NSLookup to find the DNS name of a Domain Controller and receive a valid reply. Being able to PING the Domain Controller via DNS Netbios name and FQDN are also a requirement.

A common approach to enabling support for domain join off network is to place a Read-Only-Domain-Controller (RODC) in a DMZ then make public DNS records that point to the RODC. I don’t have a DMZ and don’t like that approach and thanks to Workspace ONE UEM this type of configuration is not required. Instead I’m going to establish line-of-sight by using VMware Workspace ONE Tunnel which loads prior to Windows login to gain line-of-sight.

VMware Workspace One Tunnel is an agent that is installed on Windows 10 to enable per-app VPN capability. The Tunnel agent communicates back to a virtual appliance running on vCenter named Unified Access Gateway (UAG). The UAG is running the VMware Tunnel Service. This blog does not include the installation of UAG and assumes it is already up and running. This blog will cover the specific VMware tunnel configurations required to make this work.

The Workspace ONE UEM Airwatch Cloud Connector (ACC) is expected to already be installed and configured to use your existing Active Directory. If you do not yet have the ACC installed and configured to connect to your existing Active Directory, VMware publishes a guide here to get you started. Return to this blog when you have a functional ACC.

I’ve organized this blog into 8 parts which must be followed in the order listed but if you are a visual learner, before embarking on the long read ahead, you might find some value in watching Brooks Peppin’s 5-minute video on the process:

Part 1: DNS

In this setup, DNS must resolve the fully-qualified-domain-name (FQDN) and the Netbios name of the Windows Active Directory Domain Controller for both internal and external devices. From outside the network, the VMware Unified Access Gateway (UAG) will use the VMWare Tunnel service to connect to your internal network. The steps below offer one of many methods available to configure Windows DNS and a Hosted public DNS service to function as required. If you are on a corporate network all you need to do is obtain an externally facing DNS name for the UAG Tunnel Configuration used later in this guide and you can move on to Step 2 of this guide. For home lab set ups or first timers, below is a method that works for me.

  1. In my network I use a set of Microsoft AD integrated DNS Servers. Leveraging a forwarding lookup zone I’m able to control DNS for external clients as follows:
    1. Login to a Windows Active Directory Domain Controller running DNS.
    2. Launch Windows Server DNS manager
    3. I have two forward lookup zones configured in DNS:
      aftersixcomputers.com
      lab.aftersixcomputers.com
      I make use of a CNAME (Alias) record named “www” in the aftersixcomputers.com lookup zone

      AD DNS records live in lab.aftersixcomputers.com

      Outside the network *.aftersixcomputers.com are the names I use, but internally the network uses *.lab.aftersixcomputers.com
    4. If you set this up, confirm that a Reverse Lookup Zone exists for the subnet that the UAG will be installed on.
    5. Select the forward lookup zone where the AD DC records reside, in my example that’s lab.aftersixcomputers.com.
    6. Right-click on the Forward Lookup zone and select “New Host (A or AAA)…”
      1. Define an internal DNS name for the UAG
      2. Assign this an internal IP address
      3. Enable “Create associated pointer (PTR) record (this creates the Reverse Lookup record).
    7. Click on the Refresh icon at the top of the DNS manager and confirm both the forward lookup zone and reverse lookup zone were successfully created.
  2. At this point it’s also a good idea to use nslookup from another device on the subnet and validate DNS resolution is working properly by doing a lookup of the records you just created.
  3. Next you need to put in place a method for the Internet to find the UAG via DNS.

    My public DNS provider hosts the DNS records that redirect the Internet to my network. Preferably this process involves a static public IP address, maybe a proxy server, or load balancer, or some other network front end device. In my setup I use a Ubiquiti UDM Pro (UDMP) at the edge and Ubiquiti has decided that the UDMP doe not need to support more than 1 public IP thus I’m forced to use port forwarding. For port forwarding to function I need to create a DNS name and an A record that points the Internet to the UDMP.

    While your public DNS hosting providers process will vary, navigate to the hosting providers admin portal and find Advanced DNS settings:
    1. In the Advanced DNS settings, create a new A Record, for example mine is vpn.aftersixcomputers.com.
    2. For the IP address, use the public IP address of your edge router, in my case it’s the public IP address of the UDMP.
    3. The host name defined here will become the name used in the configuration of the Vmware Tunnel service.
    4. With the public A record created, head over to your routers configuration page for port forwarding and setup port forwarding. By default VMware Tunnel uses Port 8443 for Per-App VPN and it uses Port 2020 for Proxy. I use both so I have 2 port forward rules. The destination IPs would be the IP you previously defined in your internal DNS.
  4. The end result of this exercise is that a device on the internet looking for vpn.aftersixcomputers.com is now able to reach the internal IP address of the UAG to establish the connection.

Part 2: Configure Workspace ONE UEM Tunnel in the Workspace ONE UEM Console:

On April 28th, 2021 VMware released version 2.1 of the VMware Tunnel App. The biggest change with version 2.1 is that the app can now be used as a full device tunnel (this requires Workspace ONE UEM Console 2102 or higher). The instructions below have been updated for Tunnel 2.1 but in the configuration below the Tunnel will continue to be used as a Per-App Tunnel. Per-App Tunnel is in line with the zero-trust principals of modern management. Consult VMware’s production documentation if you will be leveraging the full device based tunnel configuration.

  1. In UEM Console choose Groups and Settings > Configurations > Tunnel
  2. Create your Tunnel.
    1. Deployment Type = Basic (Cascade is supported just not in use in my example)
    2. Hostname = the public DNS name you defined with your hosting provider. In my case it’s vpn.aftersixcomputers.com
    3. Port = 8443
    4. Server Authentication = Airwatch SSL
    5. Client Authentication = Airwatch SSL
    6. Networking = Enabled with “Default AWCM + API traffic via Server Traffic Rules
    7. Logging = Disabled
    8. Custom Settings not configured
    9. Save the configuration
  3. While you’re in the UEM settings go ahead and configure the Device Traffic Rule Sets that enable Domain Join as follows:
    1. Under the Device Traffic Rule Sets choose Edit to bring up the “Manage Traffic Assignments”
    2. Select the Default Assignment to bring up the Device Traffic Rules menu
    3. Choose “Manage Applications”
    4. Add the following 5 Windows applications:
This rule enables access to network shares like SYSVOL
This rule enables Group Policy to continue to function off network
This rule enables access to Netlogon
While not specific to domain join, this rule is helpful for accessing mapped network drives
This rule is not related to domain join, but is helpful for your IT Admins who need to use RDP for server management off network.

4. Now that the apps are created, from the Device Traffic Rules page choose Add Rule and add each of the apps to tunnel as illustrated below:

Configure Tunnel for your AD Domain name

5. Define the domain name in the Destination. In my example machines need to join my AD domain lab.aftersixcomputeres.com so I’m using a wildcard of *.lab.aftersixcomputers.com

6. Choose Save and Publish

Part 3: Enable the UAG Tunnel

The next step is to link the UAG to the UEM Tunnel configuration. This is done using the UAG Admin portal:

  1. Launch the UAG admin portal from your web browser by opening https://yourUAGDNSname:9443/admin
  2. Under General Settings > Edge Service Settings > click Show and then click the Gear icon under Tunnel Settings
  3. Choose Enable Tunnel Settings
  4. Define the API Server URL in the format
    https://ASxxx.awmdm.com
    where xxx equals the UEM Console url.
    For example if UEM is https://CN135.awmdm.com use https://AS135.awmdm.com
  5. The API Server username and password is any account on the UEM server that has been granted API access rights. By default the role “Console Administrator” has this permission. Note that what you type here must match the login format used for UEM. In my lab that means the username typed in here is lab\bgarmon
  6. The Org Group ID also comes from the UEM server, find it by hovering over the OG name in the UEM Console and use the value found in “Group ID”
  7. The Tunnel Server Hostname is the PUBLIC DNS name you defined at the ISP. In my example it’s vpn.aftersixcomputers.com
  8. BEFORE clicking SAVE, I recommend to SSH into the UAG and tail the log files to confirm what happens next succeeds. If you have a typo in your config you won’t really see any indication in the UAG admin portal that something didn’t work but you’ll spot it immediately in the SSH logs if you do the following:
    1. From your SSH client, SSH as root to the UAG
    2. Type in (but do not press enter):

      tail -f /var/log/vmware/appliance-agent/appliance-agent.log

      The reason you can’t hit enter yet is that this log file doesn’t exist until the first time the SAVE button is pressed in the Tunnel Settings page.
    3. Make sure both SSH and Tunnel Settings page are visible on your screen at the same time. In the Tunnel Settings click SAVE and immediately switch to SSH and press enter to send the tail command. You should immediately see text scrolling in SSH. The screenshot below shows what you should be looking for to confirm success
  9. Flip back to the UAG General Settings page you should find a Green icon under the Edge Service Settings next to Tunnel.
  10. You’ve completed the UAG Tunnel Configuration. Next up are the Windows 10 device settings configuration.
SSH output for Tunnel Settings showing successful configuration

Part 4: Add the VMware Tunnel app for Windows to the Workspace ONE UEM Console

Beginning with VMware Tunnel for Windows version 2.1 the app can now be used as a full device tunnel, assuming your UEM console is running 2102 or higher. The instructions below have been updated for Tunnel 2.1.1 but in the configuration below the Tunnel will continue to be used as a Per-App Tunnel as Per-App Tunnel is in line with the zero-trust principals of modern management. Consult VMware’s production documentation if you will be leveraging the full device based tunnel configuration.

  1. Download VMware Tunnel for Windows version 2.1.1 from https://My.workspaceone.com
  2. Browse https://images.google.com and download an app icon for Workspace One Tunnel to use later in this process.
  3. In the UEM Console choose Apps & Books > Applications > Native > choose Add Application > Upload
  4. On the Edit Application fill out the tabs as follows:
    1. Details tab: Name > Change this to VMware Tunnel for Windows
    2. Details tab: Supported Processor Architecture: 64-bit
    3. Details tab: App Version: 2.1.1
    4. Details tab: Current UEM Version 2.1 (this might read Version if you are on a UEM build prior to 21.01)
    5. Files tab: App Uninstall Process: Custom Script Type: Input
    6. Files tab: App Uninstall Process: Uninstall Command:
      VMwareTunnelInstaller_2.1.1.exe /uninstall /Passive
    7. Deployment Options tab: How to Install > Install Command:
      VMwareTunnelInstaller_2.1.exe /install /Passive /norestart
    8. Deployment Options tab: How to Install > Installer Reboot Exit Code: Leave this blank
    9. Deployment Options tab: How to Install > Installer Success Exit Code: Leave this blank
    10. Deployment Options tab: When To Call Install Complete: Choose Defining Criteria and select Add select Criteria Type File Exists with a path of
      C:\Program Files\VMware\Workspace ONE Tunnel\VMwareTunnel.exe
      Version 2.1.1.0
    11. Images Tab: Choose Icon Tab > Upload an image file for Tunnel app
    12. Choose Save & Assign
    13. In the Assignment Distribution menu give it a name like “Tunnel for Windows Default
    14. Choose an Assignment Group
    15. Change the App Delivery Method to Auto
    16. Choose the Restrictions menu on the left and enable “Make App MDM Managed if user installed”
    17. Enable “Desired State Management”
    18. Choose Create
    19. Choose Save
    20. Choose Publish

Part 5: Create a UEM Device Profile for VPN

  1. In the UEM Console choose Devices > Profiles & Resources > Profiles
  2. Choose Add > Add Profiles > Windows > Windows Desktop > Device Profile
  3. Under General give the profile a name and assign it a SmartGroup
  4. Choose the VPN payload and fill out the following:
    1. Connection Name: It now defaults to “Default VPN”
    2. Connection Type: Workspace ONE Tunnel
    3. Device Traffic Rule Sets: Default – Default
    4. Under Custom Configuration XML add the following XML which is how the Tunnel is configured to launch before the Windows 10 Login screen appears:
<?xml version='1.0' encoding='utf-16'?>
<CustomConfiguration>
  <StartTunnelPreLogon>true</StartTunnelPreLogon>
</CustomConfiguration>

5. Configure the Trusted Network Detection to be the name of your domain. What this setting does is to ensure that when your device is on the trusted network, the Tunnel will not be established.

6. Under DNS Resolution via Tunnel Gateway you must define how DNS will be resolved. The end goal is to make Tunnel aware of when it will use the internal DNS servers. This area of the product has been enhanced in the latest UEM Console release so you now have two options to choose from: Enable Enhanced Domain Resolution, or Disable Enhanced Domain Resolution and define the Domains.

If you enable Enhanced Domain Resolution, Tunnel will read the Device Traffic Rules and use the Device Traffic Rules to define the domains. I suspect this may be a better method to use in production, but it’s a new setting I haven’t worked with much so experiment at will. In my example I set Enhanced Domain Resolution to Disabled and I’m defining *.lab.aftersixcomputers.com and lab.aftersixcomputers.com in the domain list.

The end result of your profile should look similar to this (taken from Workspace ONE UEM Console 2102):

Windows 10 Device Profile for Custom Tunnel Configuration

Part 6: Adjust Active Directory

To join a domain on behalf of another device, an AD User Account is needed that has permissions to join computers to the domain using Delegated permissions. To complete these steps you need access to Active Directory Users and Computers (ADUC). ADUC is installed by default on all Domain Controllers or the tool can be installed on Windows 10 using the RSAT installation files.

To join a domain on behalf of another device, an AD User Account is needed that has permissions to join computers to the domain using Delegated permissions. To complete these steps you need access to Active Directory Users and Computers (ADUC). ADUC is installed by default on all Domain Controllers so you can complete the configuration directly on your DC, or the tools can be installed on Windows 10 using the RSAT installation files.

  1. Launch ADUC
  2. Navigate to yourDomainName.com > Users
  3. Right-click on Users.
  4. Choose New > User.
  5. As seen in the photo below, I’ve named mine UEMDomainJoin, set a complex password, set password not to expire and set user can not change password.

The next step is to figure out where the computer object will be created when a computer joins the domain. The default Container named Computers is where the Windows OS domain join process creates computer objects by default, but the Domain Join process only supports an OU so you will need to create a new OU if you do not already have one available. You must also adjust NTFS permissions to create objects in each of the OU’s. When you decide what OU to use or have created a new one complete the following:

  1. Within ADUC, navigate to the OU, right-click on the OU name from the left-hand panel and choose Properties
  2. Choose the tab Attribute Editor
  3. Scroll down to distinguishedName and make a copy of this name for use later on in this process
  4. Close the dialog box
  5. For a second time, right-click on the OU name from the left-hand panel and choose Delegate Control. The Delegation of Control Wizard will launch
    1. Click Next
    2. Click Add
    3. Type in the name of the account you just crated, in my case UEMDomainJoin
    4. Choose Check Names to ensure it resolves.
    5. Choose Ok and the results should be similar to this:
    6. Click Next
    7. From the Tasks to Delegate menu, choose “Create a custom task to delegate”
    8. Click Next
    9. From the Active Directory Object Type menu, choose “Only the following objects in the folder:”, select Computer Objects and check the box for “Create selected objects in this folder” as seen here:
    10. Click Next
    11. From the Permissions menu, choose General, Creation/Deletion of specific child objects and choose Create All Child Objects as seen here:
    12. Click Next to reach the end of the Delegation of Control Wizard
    13. Click Finish
    14. Repeat this process for each OU you plan to use for Domain Joins.

Before continuing on it is important to know that Microsoft Active Directory is designed to limit each AD user account to a total of 10 unique computer domain joins. Microsoft named this limit the Machine Account Quota. To work around the Machine Account Quota an IT Administrator could add the AD user account to be a member of the Domain Administrators Group but doing so introduces additional security risks and is not recommended. In my example the AD account UEMDomainJoin is not a member of the Domain Administrators group. The configuration challenge is that the Machine Account Quota is set at the domain level for all accounts, it can not be raised or lowered for a specific user account. Unless you have less than 10 machines in your environment, the Machine Account Quota must be changed from 10 to 0 (unlimited). Before making this change understand that making this change means ALL Active Directory User accounts that are not members of the Domain Administrators Group will now have unlimited domain joins available. To prevent this undesirable security configuration, it is necessary to implement the AD Group Policy named “Add Workspaces to Domain” which will change the default behavior of allowing every AD account to join a domain and instead only allow specific accounts to be able to join the domain. Many organizations likely already have the “Add Workspaces to Domain” Group Policy enabled, but if you do not, this policy is found in the GPO Management console under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment. It is recommended to create a new AD Security Group containing the user accounts are able to join the domain and then enable this GPO to enforce this.

Add Workstations to Domain Group Policy Settings

When you are ready to adjust the Machine Account Quota run the following Powershell:

Set-ADDomain -Identity ((Get-ADDomain).distinguishedname) -Replace @{"ms-DS-MachineAccountQuota"="0"}

To validate that the command was successful:

Get-ADDomain | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

If you prefer to make this change visually

  1. Open ADSI Edit from the Windows Administrative Tools folder
  2. Right-click on the domainDNS object
  3. Choose Properties
  4. In the Attribute editor scroll down to ms-DS-MachineAccountQuota and change the value from 10 to 0

Part 7: Re-Configure the Airwatch Cloud Connector (ACC) Server

  1. From your primary computer launch the Workspace ONE UEM Console
  2. Choose About from the lower left and make a note of the current version. You need to be at UEM 21.X for this to work.
  3. Navigate to Groups & Settings > All Settings > System > Enterprise Integration > Cloud Connector
  4. Scroll down and choose Test Connection.
  5. Ensure the version of ACC returned matches the current version of the UEM Console. If it does not, download the AirWatch Cloud Connector Installer .MSI, transfer the .MSI to your ACC server and run the .MSI to complete the upgrade.
  6. Enable Verbose logging on ACC:
    1. On ACC Server right-click on the Start menu and choose Run.
    2. Type in services.msc and press Enter
    3. Find AirWatch Cloud Connector and stop the service
    4. Open Windows File Explorer
    5. Enable “File name extensions” by choosing the View tab and checking the box named
      “File name extensions”
    6. Navigate to C:\vmware\airwatch\cloud connector\bank1\
    7. Find the file CloudConnector.exe.config
      If you do not see the file in the bank1 folder, change to the bank2 folder
    8. For the next step Notepad needs to be running as a local administrator so it has permissions to save the changes you are about to make.
      1. Open CloudConnector.exe.config.
      2. Find the following line:
        <loggingConfiguration filePath="....\Logs\CloudConnector\CloudConnector.log" tracingEnabled="false" level="Information" logFileRollSize="10240" maxArchivedFiles="20"/>
      3. Change the logging level from “Information” to “Verbose”
      4. Change tracingEnabled from “False” to “True”
      5. Save the file and close Notepad
      6. In Windows File Explorer make sure the file saved as CloudConnector.exe.config.
        (If you did something wrong you might end up with a second file named CloudConnector.exe.config.txt)
      7. Back in Windows Services start the AirWatch Cloud Connector service.
      8. Wait a few seconds to make sure the service starts, and stays running. If the service does not remain running, it means you messed up the edits. Recheck your work and try again.
      9. To confirm the verbose logging changes worked, open C:\VMware\AirWatch\Logs\CloudConnector\CloudConnector.log.
      10. Scroll to the bottom of the file and in the fifth column you should now start to see the word “Debug” and “Trace”
      11. Go back to the Windows Services .MSC and stop the AirWatch Cloud Connector Service
  7. There are 3 changes to make order to enable the Domain Join:
    1. Add the account UEMDomainJoin to the local Administrators Group:
      1. Right-click on the Windows Start Menu
      2. Choose Computer Management
      3. Expand System Tools > Local Users and Groups > Groups > Administrators
      4. Click Add
      5. Type in yourdomain\UEMDomainJoin
      6. Choose Check Names
      7. Click OK
    2. Adjust the NTFS permissions for the ACC folder
      1. Open Windows File Explorer
      2. Navigate to C:\VMware\AirWatch\CloudConnector
      3. Right-click on the folder and choose Security tab,
      4. Choose Advanced
      5. Choose Change Permissions
      6. Choose Add
      7. Select a Principal:
      8. Choose UEMDomainJoin
      9. Under Basic Permissions check the box next to WRITE

        Note: In testing this feature some people have had to give this account Modify. If things break this might be a setting to tweak
    3. Change the ACC Service to run as the account UEMDomainJoin
      1. By default ACC is setup to run as Local System account. This is fine for normal UEM operations but the Local System Account does not have rights to create computer objects in AD so the account must be changed
      2. From the Windows Services.MSC right-click on the Airwatch Cloud Connector Service Name
      3. Choose Properties
      4. Choose the Log On tab
      5. Choose “This Account,” choose Browse, add the account UEMDomainJoin
      6. Supply the password for the account
      7. Choose OK. If everything worked you’ll see this message popup:
      8. Start the ACC Service
      9. Open C:\VMware\AirWatch\Logs\CloudConnector\CloudConnector.log and check for any errors on launch

Part 8: Changes to Make in the Workspace ONE UEM Console

  1. In the Workspace ONE UEM Console navigate to Groups & Settings > All Settings > System > Enterprise Integration > Directory Services
  2. Below the Bind Authentication Type setting on this page is the Domain and Server field.

    Take a look at the value in the Domain field. The value listed here is the name that will be used by Workspace ONE UEM to join the domain. If it is not correct, fix it.
  3. Close this page
  4. This next step is optional but will save you some time if you plan to use Drop Ship Provisioning.
    1. Create a new UEM Device Tag
    2. Navigate to Groups & Settings > All Settings > Devices & Users > Advanced > Tags
    3. Choose Create Tag
    4. I named mine DSP as I plan to use this method primarily with Drop Ship Provisioning.
  5. Create an Assignment Group to be used for domain join
    1. Navigate to Groups & Settings > Groups > Assignment Groups
    2. Add Smart Group
    3. I named mine “Drop Ship Provisioning Online”
    4. For the Type, use Criteria and under Tags, add the Tag previously created.
  6. Navigate to Groups & Settings > Configurations
  7. Search for Domain Join and select it from the results
  8. Choose Add
    1. Name: This will be the NetBIOS name of the domain defined from the Directory Services Setting
    2. Domain Join Type: Currently limited to On-Premises Active Directory
    3. Assignment Name: This is anything you choose it to be that makes sense to you. I recommed this match the OU your will be using
    4. Organization Units: The OU DN you copied early gets pasted here
    5. Assignment Groups: The Smart Group you created earlier gets picked
    6. Machine Name Format: hover on the information circle to see what options you have for naming the computer and make a selection
      Note – Virtual Machines often use special characters when generating Win10 serial numbers. If you define Serial Number for the machine name, and your VM has a special character in the serial number, the domain join will fail with the error that the DNS name contains invalid characters.
  9. Choose Save And Assign
  10. Select the Smart Group named Drop Ship Provisioning Online

Congratulations!

You’ve completed the setup and with this configuration should now be able to:

  • Join a Windows 10 devices to the domain from anywhere that has Internet connectivity
  • Some additional benefits of this configuration include:
    • The ability to map network drives and access them off network
    • Use RDP off network
    • AD GPO’s will now apply off network as well
Tags:

Recent Comments

  1. Lukas D.

    Reply
    January 27, 2021 @ 7:11 am

    Hi there,

    thank you for this interesting article, if it works this would be exactly what I’ve been searching for.
    Is the version 2010 really the minimum for this? I’d like to test this with 2005.

    Is there any kind of documentation where this snippet is described for the pre logon connection and is this eventually the reason why it has to be version 2010?

    true

    Thanks and greetings,

    Lukas

    • bgarmon

      Reply
      January 27, 2021 @ 8:07 am

      Device Traffic Rules were re-designed both in the Server side configuration of them, and in how they are now applied to Personas, thus a newer console version of the Workspace ONE UEM Console is recommended.

      The pre-login connection is effectively telling the Tunnel Agent to load before a user logs onto Windows thus allowing the connection to be established before the user login.

  2. Johnny

    Reply
    May 4, 2021 @ 2:01 pm

    Thanks for sharing. It’s helpful. I’m trying to set it up but stuck in the step where ACC service > Properties > Logon tab and add AD username/password. After that, service won’t start. I’m getting error message related to logon info. When i removed the username/password, service can start. Cloud connector log shows error msg “query with error time out 12000”.

    Do you have any idea why? Thanks.

    • bgarmon

      Reply
      May 4, 2021 @ 2:56 pm

      Re-run through Part 7, starting at Step 7 which is where you set the permissions for the account. That it is not starting indicates you’ve got something wrong with the permissions set.

  3. Thierry

    Reply
    June 15, 2021 @ 5:49 am

    Hi ,
    Thanks for the share.
    i got a small issue regarding connection to external website.
    I want to block all connection to website but access only for youtube for example but no success.
    I am using chrome enterprise and blocked * and Bypass *.youtube.com
    But still blocking youtube, any idea why?

    Thanks

Leave Your Comment