Concurrency Assists National Non-Profit with Outage Recovery and DirectAccess Implementation

Background

This national non-profit advocacy group is dedicated to eliminating preventable deaths at places of employment, in homes and communities, and on roadways.

Recently this organization implemented a remote connectivity feature of Windows Server to enable user access to internal network resources when users are offsite. This feature, DirectAccess, enables transparent connections along the lines of Virtual Private Network (VPN) functionality but the connection is accomplished automatically before a user even logs into a device.

Unfortunately, the organization experienced a significant corporate network outage upon initial deployment of the DirectAccess server. Even devices directly connected to the local network were unable to access services.

To recover from the outage, the organization’s IT team tore down the DirectAccess deployment and made changes across other servers and workstations to get back to the prior state.

At that point, they wanted to regroup, determine the cause of the outage, and plan for redeployment of DirectAccess in order to benefit from its remote-access features.
For assistance with these next steps, the organization contacted Concurrency.

Solution

We began with an onsite meeting to review symptoms observed during the outage and discuss the triage applied at that time.

The basic scenario had been that upon deployment of the DirectAccess server, suddenly even local machines weren’t able to communicate with each other—even the domain controllers.

In this sense, the problem had been catastrophic in its impact—but, as it turned out, likely not too outlandish in actuality. Our experience suggested the problem had likely been a misconfiguration issue relating to the network location server.
Specifically, an aspect of the network location server is to determine which devices are inside and which are outside the local network. If the network location server goes down, suddenly even local machines are perceived to be outside the network—and therefore were shut out from communications.

We explained our belief that by shutting down DirectAccess and removing its configurations, The organizations’ s IT team had enabled the network location server to function properly once again. That meant that devices that were inside the network boundary were, in fact, recognized as being inside and could once again communicate properly.

Having established the likely cause of the outage, we then assisted them with a design for a less-complicated, simpler deployment of DirectAccess that would reduce the number of potential failures and significantly ease deduction of and recovery from any problems that might occur in the future.

One aspect of the design we suggested was to make the network location server more independent of the DirectAccess server. In this setup, even if DirectAccess were to go down, internal users would still function as normal. Furthermore, if the network location server were to go down, their IT team could easily replace its functions by creating a website on another Infrastructure-as-a-Server site. And, in the event the domain servers were to fail, the network location server would still function to make client devices behave properly.

All the steps noted so far took place on the first day of this project. By the end of that first day, we collectively determined to move forward with the redeployment of DirectAccess the following day.

On the second day, the deployment went smoothly. Working together with the IT team, we connected everything needed on the server side, conducted testing, then deployed DirectAccess to client devices.

Results and Next Steps

By the end of that second day of the project, the organization was up and running smoothly with DirectAccess functionality.

Furthermore, its IT team was well prepared to handle any issues that might arise in the future thanks to their focus on stepping back to figure out what really went wrong.

There’s often significant benefit in stepping back from a problem to observe just what went wrong—such as whether it was a product problem or a configuration problem.

The organization’s IT team took the time to really understand the issues and, even though the initial deployment created a problem, didn’t lose sight of the business benefits they were after. The team members asked lots of good questions and worked in close partnership with us.

In our experience, DirectAccess is a good example of a valuable product that has some nuances a person just wouldn’t likely be aware of except for having done many implementations over several years. We were honored to share our experience with the product and help them get up and running quickly in serving its mobile users.