in this video I go over some of the common causes of the join domain error
when deploying Windows virtual desktop
hello everyone I'm Travis and this is Ciraltos I posted an article a few
months ago to help people who maybe experienced an error with joining
Windows virtual desktop session host to domain during a deployment in this video
I go over some of the more common causes and give recommendations to resolve the
issue I also give a tip at the end that should make troubleshooting the
issue easier before that please subscribe like share and all that good
stuff it helps my channel and it is appreciated to start let's go over
what's happening in Windows virtual desktop when you run a deployment after
the session host VMs are deployed a configuration script joins the session
host to a Windows ad or azure ad domain services domain the join domain air is
caused by the script failing to join the computer to the domain Windows virtual
desktop has proved requisites it's not like app services where you can deploy
and then access by a web URL if there are any problems with these
prerequisites that will cause issues with the deployment Windows virtual
desktop requires a working Active Directory environment this can either be
Windows Active Directory or azure ad domain services if you're not clear on
the differences between the versions of Active Directory check out my video on
directory services for clarification also required is network connectivity
between the session host and the version of Active Directory you're deploying to
the domain joint-heir could have different causes based on the type of ad
you use let's start with Windows ad a Windows ad domain can be connected to
azure either by a site-to-site VPN connection Express route or you could
have a domain control or deployed to Azure or a combination any configuration
will work as long as a session hosts deploy to Azure can connect to the
windows ad domain network connectivity is dependent on the v-net the v-net
session hosts are deployed to need connectivity to a domain controller one
common problem with deploying Windows virtual
top is the default settings for deploying a host pool was to create a
new VNet by default does not have connectivity to any other VNet
that requires a VPN connection or VNet peering so if you deploy a new VNet
that vnet cannot communicate with the VNet that has access to the domain
controller and the deployment will fail with the domain join air the image on
the screen shows the settings from the azure portal notice the note that it has
to have connectivity to a domain controller also a spring update 20/20
and no longer defaults to a new v-net it asks you to select an existing VNet the
first tip is when using windows a be be sure the VNet has connectivity to the
domain controller well on the topic there's one other setting that needs to
be changed when deploying session hosts and using Windows a B the DNS servers on
the VNet has to be configured to domain DNS servers commonly set to Windows
domain controllers why is this when you add a computer to the domain the
computer uses DNS to find resources such as domain controllers for that domain if
you leave the DNS server to the default Azure public DNS server the computer
will not be able to locate domain resources and the domain join task will
fell just like on-premises DNS has to point to domain DNS servers for the
client to join the domain the DNS settings are found in the VNet
properties and apply to any dynamically assigned DNS in that beam at tip 2 is
when using Windows ad set the DNS servers on the be met to the domain DNS
servers let's move on to Azure a B domain services next if this is the
configuration you're using and having problems take a look at my video on
deploying azure ad domain services and joining a computer to the domain this
will give you insight into the details of how to deploy and configure Windows
ad domain services and then join a computer to that domain just like
Windows ad session host joining an azure ad domain services domain need
connectivity to the domain be sure to deploy the session host to a VNet with
connectivity to the domain this is typically done by adding them to the
subnet and the same v-net as a domain services alternatively you can
deploy the session host to a different v-net as long as there's connectivity
with VPN or v-net peering before the host is deployed the third tip when
using Azure ad domain services be sure the session hosts have connectivity to
the domain you can probably spot a theme here just like Windows ad azure ad
domain services is dependent on DNS the session host will use DNS to locate the
domain resources when join in the domain be sure to complete the azure ad domain
services setup by updating the DNS server setting on the B net also if you
do deploy to a different B net for Windows virtual desktop the DNS settings
will need to be manually updated on that v-net also tip for when using Azure ad
domain services be sure that DNS server settings are updated something else to
be aware of with Azure ad domain services user accounts for azure ad
domain services can be sourced from windows a be replicated to Azure ad and
then to Azure ad domain services or they can be created in Azure ad and then
replicated to Azure ad domain services or simply created in Azure ad domain
services if you deploy Azure ad domain services and use a domain joint account
sourced from Azure ad be sure to change the password on that account after
deploying Azure ad domain services here's why Azure ad stores a hash of the
password but it's not in the legacy and tell'em format needed by azure ad domain
services Azure ad also does not store the password in a format that it can
generate the legacy and tell'em hash from with Azure ad domain services are
deployed to the tenant the azure ad tenant will start creating the legacy
ntlm password hash format the next time the user changes their password so if
the password for the domain joint account is not changed there's no valid
password hash in Azure ad domain services and you'll get an account
disabled or locked out error message so my fifth tip when using Azure ad source
domain joint accounts change the password on the domain joint account
after deploying azure ad domain services speaking of domain joint accounts
if using Azure 18 domain services with accounts synchronized from windows ad
legacy ntlm hash synchronization has to be configured in AD connect this is
different from password hash synchronization used for azure ad check
out my video on Azure ad domain services for more detail at this point there
should be connectivity between the session host and the domain services DNS
is in place and the password synchronizing the next thing to verify
is that there's no network security groups blocking traffic between the
session host and the domain controllers network security groups can be applied
to the network interface or the subnets if you have network security groups in
place make sure that they're not blocking communication between the
session host and the domain controllers tip number 6 make sure there's no
network security groups blocking traffic between the domain controllers in the
session house that takes care of the most common issues I have one more
recommendation if you're still troubleshooting the issue after checking
the above this removes Windows virtual desktop from the equation to isolate if
the problem is Windows virtual desktop or something else in the environment
deploy a Windows VM it can be Server 2016 2019 or even Windows 10 deploy to
the same v-net and subnet that you're deploying the session house to once
deployed use the same domain join username and password combination used
for the Windows virtual desktop deployment to add the computer to the
domain if it fails that means there's a problem with the prerequisites and the
Windows virtual desktop will fail also this will help identify if the source of
the issue is Windows virtual desktop or something else in your environment so
the last tip join a computer to the domain from the same subnet and with the
same domain joint account outside of Windows virtual desktop I hope this
helps with identifying the issues causing domain joint-heirs if you have
any other tips please add them to the comments below thanks for watching