DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.
Global Settings
There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.
Parallel Deployments
To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.
Common Use Cases
QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.
Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.
Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.
Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.
Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.
Requirements
To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:
Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.
Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.
Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.
Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.
Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.
Supporting Infrastructure
The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.
Migration Process
Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.
Summary
DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.
Steve Burkett
/ August 18, 2015How about when wanting to have some laptops/users with full DirectAccess connectivity to internal resources, but the rest of the deployed laptops as only having DirectAccess to management servers (such as ConfigMgr and AV servers) for reporting and remote management purposes? Should we again be using two DirectAccess instances for that scenario?
Richard M. Hicks
/ August 18, 2015Yes, that would be another excellent example of the use of parallel deployments. Full access vs. management only configuration is global in scope, so you’d have to choose one or the other. Having two deployments allows you to tailor those requirements to your specific needs.
Richmond Howie
/ August 20, 2015Thank you for another one of your as ever helpful posts. I do have one question regarding this topic. What are the impacts on the DNS entries created by DA, in particular the AAAA record for directaccess-corpConnectivityHost and the A record for directaccess-WebProbeHost? Will it overwrite the existing entries or have multiple entries for the same name, but then how to limit specific clients to only resolve the entries valid for them?? Apologies for my ignorance with the DNS records, I had a read through your posts on DNS records created and the fact that multi-site will have multi values for the second record, but this is a multi-deployment model which is obviously different.
On a different topic, have you come across issues using ECC certificates for the certificate used to authenticate IP-HTTPS connections?
Richard M. Hicks
/ August 24, 2015Hi Richmond,
In a multisite deployment you will have multiple entries. They won’t overwrite each other. As for using ECC certificates for the IP-HTTPS listener, I can’t say that I’ve encountered that scenario as of yet. I haven’t heard of any issues, however. If your experience is different, please let me know!
Anton Brauchli
/ September 24, 2015Hi Richard
How about a Scenario where all Systems, independent where they are coming from, will connect to DA. Also all internal clients.
Initially the plan was to connect all systems to the same DA instance but then we don’t have the ability in SCCM to differ where the clients are coming from. This is important to us because we don’t want to allow SCCM traffic when the clients are connecting from external sites to avoid possible mobile telecom costs.
Richard M. Hicks
/ October 1, 2015Perhaps I don’t understand the use case clearly, but I can’t see why having internal clients connect via DirectAccess would be a good idea. I’m not sure there’s a good way to address the SCCM traffic issue over mobile networks either. DirectAccess only detects inside or outside, and if outside will establish a DirectAccess connection. It doesn’t have the capability to distinguish between types of network connections (Ethernet, Wi-Fi, cellular, etc.). I don’t know enough about SCCM to say for sure, but perhaps there’s a detection method that can be used by SCCM to detect the link type?
Steve Burkett
/ October 1, 2015Windows 8 and 10 clients have built-in metered internet connection types for interfaces, and SCCM will honour those and not download using that interface, unless you force to override for a particular deployment (e.g. emergency patches). Windows 7’s not that intelligent though.
Craig
/ October 6, 2015Richard,
Slightly off topic for the above post but I couldn’t find one specifically talking about multi-site.
I have a single site, single server 2012 R2 DA set up running with only Windows 7 clients at present – no OTP configured either.
I want to start adding three more servers in different geographical locations but at the same time our business will be gradually moving to Windows 10. My question is can I run a multi-site DA deployment with both Win 7 and Win 10 clients concurrently and if so are there any pitfalls? I already understand the limitation of Win 7 clients having to be associated with a single DA entry point but is there anything else?
Cheers
Craig
Richard M. Hicks
/ October 7, 2015Hi Craig,
You most certainly can. The only drawback for Windows 7 clients and multisite is that the lack of automatic site selection and transparent failover, but if you’re willing to accept that limitation there’s nothing else that should stop you from deploying multisite. As and when you begin to roll out Windows 10, those clients will take advantage of those features along with IP-HTTPS performance improvements too. 🙂
Craig
/ October 7, 2015Thanks again 🙂
Craig
/ October 19, 2015Richard,
Again on multisite rather than multi instances; can you add sites on an ad-hoc basis? By that I mean can I add subsequent entry points whenever I choose after enabling multiste or must all entry points be added when running the wizard.
Cheers
Craig
Richard M. Hicks
/ October 20, 2015You can add additional entry points ad-hoc, yes. Once you enable multisite you can add additional entry points at any point in the future, as needed.
Craig
/ October 20, 2015Great, thanks again.
Damien
/ January 4, 2016I am trying to configure this setup but I have run into an issue whereby I cant select to use a self signed cert on Step 3 of the wizard for the network location server. Is there a way around this?
Richard M. Hicks
/ January 4, 2016This happens when a computer certificate has been issued to the DirectAccess server. You can choose to keep and use that certificate, or delete the certificate and use a self signed certificate (not recommended). Keep in mind that if you delete the existing machine certificate, you won’t be able to support Windows 7 clients or a variety of other important features that rely on certificate authentication (e.g. load balancing, multisite, etc.).
Damien
/ January 5, 2016Thanks for the reply. The primary DA site cluster consisting of two DA servers both with the NLS on them is using the default self signed cert “DirectAccess-NLS”. This site is working fine. The new secondary site (not part of multisite deployment) is the one I’m having trouble with. I managed to get around this by issuing a new web certificate from my internal CA called NLS. DA is currently working on both sites now but when trying to add a second server to the new setup I got an error relating to the NLS certificate not being valid and I could not proceed. I was seeing the exact symptoms mentioned here: https://support.microsoft.com/en-us/kb/2799664
I ran that PowerShell script which hung and did not return the prompt. I left it for 10 minutes and still nothing so I cancelled it. After rebooting the servers it has been added. Step 3 of the wizard still shows as an invalid certificate but all is working.
Richard M. Hicks
/ January 5, 2016This illustrates precisely why it is best to host the NLS off-box when configuring DirectAccess in load-balanced and/or multisite deployments. Glad you got it working though. 🙂
cwhitmore88
/ January 17, 2016Richard,
I just viewed some of your videos on DirectAccess on PluralSight. Great information!
We currently have 110 folks distributed across six locations with our main site in Austin, Tx. I’ve setup Windows 2012 R2 data center running as DC, DNS and SCCM 2012 R2 at each location. SCCM 2012 R2 runs IIIS to support PXE boot for OS deployments.
Can I run Apache (to support NLS without breaking SCCM), NLS and DirectAccess on these six servers? (All locations are connected via private VPN from ISP.)
Thanks,
Carlton.
Richard M. Hicks
/ January 18, 2016Hi Carlton,
Running DirectAccess on a domain controller isn’t expressly unsupported, but it certainly isn’t recommended. You’ve also got quite a few workloads running on the server already, so I’m not sure what the experience is going to be like. DirectAccess is CPU intensive and adding it to your existing server may result in degraded performance for all services.
You can run Apache for the NLS, but it is also possible to set up a separate web site on the IIS server without disrupting anything else. Just make sure you use a unique host name to access the NLS web site, not the name of the server. 🙂
cwhitmore88
/ January 18, 2016Richard,
I have all Windows 7 Pro and Enterprise clients running. But we have a small number of clients that work from home 50% or more so I could easily upgrade them to Win7 Enterprise or Win10 Enterprise. Ideally I would like to setup DirectAccess and NLS at our Austin site with NLS redudancy at our El Paso office (El Paso is connected via private VPN to all locations including Austin.)
What setup would you suggest? We’re a non-profit, but we get Microsoft licensing at a huge discount.
Thanks for your help on this,
Carlton.
Richard M. Hicks
/ January 19, 2016High availability for the NLS will help prevent potential connectivity disruptions for DirectAccess clients on the corporate network. If you get to Windows 10, I’d strongly encourage you to implement DirectAccess multisite for geographic redundancy as well. 🙂
Venelin Ustabashiev
/ April 13, 2016Hi Richard,
I got single site with 200 remote users. If I convert the site to multisite, do I need to bring users back to apply new GPO? Are my users will lose connection?
Thank you!
Richard M. Hicks
/ April 13, 2016Yes, that’s correct. Switching from single site to multisite DirectAccess will result in the IPv6 addresses used for IPsec tunnel endpoints changing. When this happens, clients are immediately disconnected and won’t get the updated information until they update group policy, which obviously can only happen when they are connected to the LAN again (either directly or via some other VPN technology).
mfekry86
/ April 16, 2016Hi Richard, is direct access able to provide multiple policies based on access level required , for ex i need some users to connect for patching only , and other users be able to access the other corporate resources . or am still need a separate & multiple deployment for each access level
appreciate your help
Richard M. Hicks
/ April 23, 2016No, it does not. DirectAccess policies are applied globally to all provisioned clients. If you require different levels of access for specific users, it would require a separate deployment.
Engineering IT
/ April 17, 2016In the article is says “Note: It is not possible to change the names of DirectAccess GPOs after initial configuration is complete. The only way to change GPO names after DirectAccess has been configured the first time is to remove the configuration completely and start over.”
However I’ve found if you just rename the GPO using Group Policy Management Console, the updated GPO name is reflected in the Remote Access Administration console. It must query the GPO GUID and not the name.
Richard M. Hicks
/ April 23, 2016Thanks for pointing that out! In the past that was the case, but it appears at some point Microsoft resolved that limitation. I’ll update the post to reflect this. 🙂
Edward
/ September 23, 2016Hi Richard! From searching the internet for tips and tricks for DirectAccess you seem to have the most experience by far. These posts are extremely helpful. My question is about two single DA deployments in parallel, within the same domain, each running 2012 R2…When publishing the secondary DA configuration, there seems to be no way around the newly renamed GPO’s to be linked at the root domain level. However it seems that security filtering does not do its job properly and the GPO applies to laptops within the organization that shouldn’t receive the configuration, therefore causing issues internally until it is manually addressed. I contacted Microsoft and they mentioned that renaming the group policies of “Direct Access Clients (or Servers)” puts it in an unsupported configuration, and they can only suggest using a different domain. What are your thoughts on this? They couldn’t answer my question of why we have the ability to change the GPO names if it makes it ‘unsupported’. Keep in mind this is all through the DirectAccess Management Console, so we’re not changing directly. I’m trying to stand up a second deployment for the exact reason you mention in this post, so I do not disturb production, however when publishing it causes weirdness with GPO’s that are applied that shouldn’t be.
Richard M. Hicks
/ September 24, 2016Hi Edward. Glad you are finding the web site useful and informative. 🙂
I think you got some bad information regarding the renaming of GPOs and its effect on DirectAccess supportability. It is possible to change the names of GPOs using the Remote Access Management console when you first perform the initial configuration of DirectAccess, and I commonly make this change. If it wasn’t supported, I don’t think they’d provide the ability to change them in the UI. Also, it is not mentioned at all in Microsoft’s formal unsupported configuration guidance published for DirectAccess here – https://technet.microsoft.com/en-us/windows-server-docs/networking/remote-access/directaccess/directaccess-unsupported-configurations.
As for security filtering not working, it sounds like you might have enabled the option to apply DirectAccess settings to all mobile computers. That is definitely not recommended. Check your configuration and disable that option if it is enabled. Also, make sure you are using unique security groups for each DirectAccess deployment, and that DirectAccess clients are members of only one of those groups at a time. If they belong to both it won’t work.
Edward
/ September 26, 2016Noted, thank you sir. I did check both items you had mentioned — Apply to all mobile computers is not selected, and we are in fact using unique security groups. For what its worth i got an update from Microsoft, and they are stating that the issue is because both single server deployments are in the same site/domain, which could be causing the problem. Based on your information here it looks like that shouldn’t be an issue?
It seems that they are grasping at straws at the moment, but at least wanted to mention. They are escalating, and i pointed them in the direction of this article showing that a Microsoft MVP in this area of expertise has some information that may be of use to them. I hope they help me get this sorted out! In the meantime, do you see any issue with it being a same site deployment as the current production possible be an issue? -Edward
Richard M. Hicks
/ September 28, 2016I am not aware of any issues with deploying multiple instances of DirectAccess in the same domain and AD site. That doesn’t mean there isn’t something I’ve not yet encountered, however. If you are unable to get satisfactory resolution with Microsoft, drop me a note directly and I’d be happy to provide some assistance and guidance for you.
Jerome Haltom
/ November 6, 2016Multi-site question. I have two DA servers. Same network. But, I can’t use real load balancing. VMware, etc.
So, I set them up as two sites. The first works just fine. The second however does not.
When connected to the second site (which I can specify manually), IPv6 traffic flows. I can ping machines on the other end. But name resolution does not.
There is only one DNS address being put into my clients NRPT. It is reachable when connected to the first DA site. But not the second.
Teredo is working with both. 6to4 is disabled.
Any clues here? It seems weird to only have one DNS64 address being in the NRPT. I’d think that would need some mechanism to be changed per-site.
Richard M. Hicks
/ November 7, 2016This is a known issue. When deploying multiple DirectAccess servers on the same subnet in a multisite configuration, you must also disable duplicate address detection by issuing the following command in an elevated PowerShell command window on each DirectAccess server.
Set-NetIPInterface –InterfaceAlias –AddressFamily IPv6 –DadTransmits 0
Hope that helps!
Cory
/ November 30, 2016I have an existing DA server that I had been running on Hyper-V. I migrated the server to VMWare and the NIC changed. When I try to go back into step 2 to change the nic to the new one, I get an error message stating that ipv6 is not configured on the new nic when it has been.
From what I’ve read, the DA configurator sets the ipv6 info at initial install time and that I would have to delete my config and start over again. Or I could install a 2nd server and move everyone over to that one.
My question is twofold:
1. is there a way to change a nic easily in DA without wiping out the config that is currently set?
2. if I create a new server, is there a way to migrate those users to the new server without a direct link to the LAN? all of the stations affected are mobile users, and they are scattered throughout the country. There is only one homebase and no real satellite office with a more direct connection to the LAN. I’d rather not have to ship replacement machines to all of my remote users if I could prevent it.
Thank you for your time.
Richard M. Hicks
/ December 15, 2016I think it might be possible to hack the DirectAccess server GPO to reflect the change of network adapter. I’ve never done it myself, but if you look at the new value of InstanceID when you run Get-NetAdapter and update that detail in the GPO it might work. You could easily add another server to the cluster and you wouldn’t have to update any settings at all. If you created a new DirectAccess deployment you’d have to get clients connected to the LAN to update the settings.
Mark
/ May 4, 2017Thanks for providing such reliable guidance for DA configuration and best practices. Your videos and website are gold (esp your newest DA 2016 video on Pluralsight)! We recently expanded our DA configuration to multisite and now have a single server in each of two datacenters. Everything is working but I found that the DA Server GPO is filtered to apply only to the original/first server. Is that the correct outcome for a multisite installation (no clusters, no load-balancing)?
Richard M. Hicks
/ May 5, 2017Hi Mark! Thanks for the kind words. Much appreciated! As for your DirectAccess configuration, there should be a unique GPO for each entry point, filtered to the server or servers that belong to that entry point. If everything is working correctly, there has to be another GPO in your Active Directory somewhere. 🙂
Mark
/ May 5, 2017Ah of course…and there it is! Once again your guidance is appreciated…seems I didn’t modify that policy label to align with the previous/original and so it got lost in the list of our GPOs. Cheers!
Richard M. Hicks
/ May 9, 2017🙂
Vinnie
/ July 18, 2017Hi Richard, I have 2 single DA servers in the organisation. I got 2 directaccess-WebProbeHost in DNS. All network is IPv4. I got 1 ectaccess-corpConnectivityHost 127.0.0.1. Do i need to have 2 directaccess-corpConnectivityHost AAAA IPv6? When i ping directaccess-corpConnectivityHost from 2 diferent client i got 2 diferent IPv6 responds. Thank you.
Richard M. Hicks
/ July 20, 2017If you have two separate DirectAccess deployments, then you should have one entry for directaccess-corpConnectivityHost that resolves to the IPv4 address 127.0.0.1 and two entries that each resolve to the IPv6 address beginning with your NAT64 IPv6 prefix for each deployment and ending with ::7f00:1. For the record though, DirectAccess seems to work without issue even if these DNS entries are not present (at least with 6to4 and Teredo disabled anyway).
Sun Jianyao (@pinkfloydsjy)
/ May 21, 2018Hi Richard
109/5000
I’m working on how to properly deploy DA. Your website and books have provided me with great help. Thank you very much. Now that I have a problem, we plan to use a single NIC and put it in the topology behind the NAT device. Now that the load balance has been implemented using the NLB, if i want to deploy multiple sites, whether a single NIC is allowed？
Looking forward to your reply.
Richard M. Hicks
/ May 21, 2018Yes, you can deploy DirectAccess in a multisite configuration using a single NIC. In fact, you can even mix and match if you like. One entry point could have single NIC DirectAccess servers and another point could be multihomed. You just need to make sure that all DirectAccess servers in the same entry point are configured identically (single or multi-NIC).
Vas
/ October 10, 2018Hi Richard
I am currently running a parallel Direct Access 2016 environment with an external load balancer. This environment has been setup exactly the same way as the working prod environment.
I have come across a couple of issues which I am not sure if they are related to each other.
1. The client computer trying to connect to the new environment is coming up with an error “Action needed – Windows Firewall must be turned on” This error does not appear when connecting to live environment
2. On the client machine the NRPT table becomes corrupt when moving the computer object from the old DA environment to the new one. I have had a look at the registry and found two sets of IPV6 addresses (old DA server and new Da server) in the DNSPolicyConfig entry
Your help is much appreciated.
Richard M. Hicks
/ October 13, 2018Unusual. The only thing I can suggest is that you make certain that your DirectAccess client belongs only to a single DirectAccess security group at a time. If your client is included in both groups (old and new) you’ll have all sorts of problems.
Vas
/ October 14, 2018Hey Richard.
Thanks for your response. Thought I post the my findings in case someone else comes across similar problems. It appears that the issue was GPO related. Both the old and new ” Direct Access Client Settings” GPO’s was applying to the client machine causing all sorts of problems. I had to block GPO inheritance on the OU the new GPO was linked to then force a GPO update. I then checked that the new GPO was the only one applying and confirmed that everything started to work. A pretty simple mistake but I overlooked the way that the old GPO was applying to the rest of the environment.
Thanks again.
Richard M. Hicks
/ October 20, 2018Thanks for the update!
José A. G. Barceló
/ August 27, 2020Hi Richard,
In the “Migration Process” section you talk about creating a staging OU for clients in the old deployment and a production OU for clients to be assigned to the new deployment. What should we do if we are already using OUs in order to apply other different GPOs (such as Folder Redirection, Offline Files or Certificate Enrollment) and those clients cannot be moved from/to another OUs without breaking other things? Are there any alternatives? Can security filters do the job instead of using OUs in order to limit the reach of the new Direct Access GPOs?
Thank you for your time and effort.
Richard M. Hicks
/ August 28, 2020You will have to assign any required GPOs to the staging OU to ensure that everything works as expected. Nothing prevents you from linking a GPO more than once, so this shouldn’t be an issue.
Matthew Harrison
/ September 8, 2020Hi Richard,
I already have a DA Setup on 2012 r2 – In DNS there is directaccess-corpConnectivityHost, DirectAccess-NLS & directaccess-WebProbeHost.
We are migrating to a new server, different site, Windows 2019, different external IP but on the same domain and dns setup (MPLS Network) When going through the DA setup wizard on the new server, i assume it will create or overwrite those current DNS entried? Is that the case? if so how do i go about setting up a parallel server?
Richard M. Hicks
/ September 9, 2020That’s correct. The new install will overwrite those settings. However, that’s ok because most will still work for the old deployment. The exception would be NLS. You can share the NLS between deployments if you configure it on a separate server. You can’t really use the new NLS hosted on the new DirectAccess server for the old deployment unless you went through a lot of additional work. You’d be better off switching to external NLS. 🙂
John McGregor
/ January 5, 2021I have recently built a second directaccess server because our external domain name has been changed due to an acquisition. I tried to change the external connect url but had issues so decided to build a new solution on Windows server 2016,then migrate computers to the new security group.When I came to the problem with webprobehost I changed the suffix and created a manual dns entry in the new zone so it didn’t affect the original solution, but I can’t get the new solution working. It may be because I now have multiple corpconnectivity host entries.
Richard M. Hicks
/ January 6, 2021You can have multiple directaccess-corpConnectivityHost DNS entries without negatively affecting DirectAccess connectivity. In fact, this entry can be removed entirely and DirectAccess should still work. The directaccess-WebProbeHost must be present for the client to accurately report DirectAccess connection status though. It should resolve to the IPv4 address of one of your DirectAccess servers.
Semi
/ January 17, 2022Hi Richard,
if i already have two direct access servers in a cluster running server 2016 and i want to add two more, should i use 2016 or is it irrelevant if i use 2016, 2019 oder 2022?
Thanks in advance 🙂
Richard M. Hicks
/ January 20, 2022You can add servers with newer operating systems to an existing cluster. I’ve done this numerous times without issue. I’ve used this process to perform rolling upgrades for existing Windows Server 2012 R2 or 2016 deployments.
Kamil
/ March 16, 2023Hey Richard,
I wonder if you still check on comments here 😉
I have an issue, I hope you might help, with adding new Entry Point to existing multisite DA setup. We have 4 DA servers running in different regions/AD sites, all 2012R2, recently I’ve added new 2019 DA server in new site, all went smooth, now I’m trying to add new 2019 in same site (different subnet) as one of the 2012R2 DA servers and its failing with ‘ is not associated with an Active Directory Site’ error. DA server Subnet/32 is added to AD Sites & Services, Public IP and DNS names are different, I’m not sure what else might need to be done here?
Richard M. Hicks
/ March 16, 2023I do check comments on old posts. 🙂 Not sure what’s up here, to be honest. If you could create a new additional site and install a server, I would expect you to be able to add more without issue. Unfortunately, I don’t recall encountering this specific error in the past, so I don’t have any experience to draw on. I was going to suggest making sure AD sites/services are configured with the correct subnets, but it sounds like you’ve done that already. Sorry I don’t have any helpful guidance for you here. :/
Ruben
/ August 9, 2023Hi Richard,
First, I wanted to congratulate you for providing such amazing support for everyone. I have access to your content via Pluralsight, as well as your books for Direct Access and AOVPN, and they’ve always been of tremendous help. I was wondering if you knew a way around this issue. Long story short, we’ve been having an issue with internal certificates, and our main DA London site stopped working, clients were going to limbo not establishing Kerberos v5 connection (we could see it on the FW view). Initially, the multisite deployments weren’t working, but we managed to get them working again after removing them from the configuration and then adding all back again. Now, after spending weeks checking everything, we decided to recreate the site from scratch.
Our current issue – When going through the wizard setup to enable a multisite deployment, you need to enable IPsec auth. When I do so in the Remote Access Server by choosing our Root CA (exact same certificate we were using before), the console gives an error: “The remote procedure call failed.” I have checked the event logs and scoured the internet, but I can’t find a way around this. I have tried many things with no luck. When running the wizard and choosing the Root CA cert from the beggining instead of our wildcard, it also fails. However, choosing wildcard and leaving user computer certificates option off, redeployment goes fine.
Any advice? I’ve run out of ideas here.
https://opus2miscellaneous.blob.core.windows.net/opus2images/X.jpg
Richard M. Hicks
/ August 9, 2023Hi Ruben. Thanks for the kind words. Much appreciated! As for your DirectAccess issue, I’m not sure to be honest. RPC calls failing might indicate a conflict with a firewall, either host-based or network-based. That’s the most common thing in my experience. Make sure the ‘Domain’ Windows Firewall profile is loaded on each of your DirectAccess servers. If you have network firewalls between those hosts, you should have a close look at the logs on those devices to ensure all RPC traffic between DirectAccess servers is allowed.