All posts in category Update

Always On VPN Updates for Windows 10 2004

Always On VPN Updates for Windows 10 2004Microsoft recently made available an update for Windows 10 2004 that includes many important fixes for outstanding issues with Windows 10 Always On VPN. KB4571744 (build 19041.488) addresses many challenges faced by Always On VPN administrators today, including the following.

TPM

This update addresses an issue that prevents hash signing from working correctly using the Microsoft Platform Crypto Provider for Trusted Platform Module (TPM). This issue can occur when administrators configure Always On VPN to use Protected Extensible Authentication Protocol (PEAP) with client certificate authentication using a FortiGate security device.

Sleep/Hibernate

This update also addresses issues with Windows 10 Always On VPN failing to automatically reconnect when resuming from sleep or hibernate. I’ve written about issues with Always On VPN and sleep/hibernate in the past. This is an issue that has plagued Always On VPN since its introduction, so let’s hope this finally provides some meaningful relief from this persistent problem.

Certificate Authentication

When both the Always On VPN device tunnel and user tunnel are provisioned to a Windows 10 clients, user tunnel connections may be authenticated using the machine certificate and not EAP/PEAP. This can result in connections that are not validated as intended, and allowing a user to bypass configured NPS policies, MFA requirements, or conditional access rules. This update includes a fix for this issue, restoring proper authentication for the user tunnel when the device tunnel is also provisioned.

Device and User Tunnel Coexistence

A bug that first appeared when Windows 10 2004 was introduced prevented a device tunnel and user tunnel Always On VPN connection from being established to the same VPN server if the user tunnel used Internet Key Exchange Version 2 (IKEv2). This update restores full functionality under those conditions.

Update KB4571744

To resolve these issues with Windows 10 Always On VPN as well as others, download and install update KB4571744 today. If you are experiencing any of these issues with releases of Windows 10 prior to 2004, look for updates for those build to come later this year.

Additional Information

September 3, 2020 – KB4571744 (OS Build 19041.488) Preview

Windows 10 Always On VPN Connection Issues after Sleep or Hibernate

Windows 10 Always On VPN Bug in Windows 10 2004

11 Comments
by Richard M. Hicks on September 7, 2020  •  Permalink
Posted in Always On VPN, AOVPN, authentication, certificates, device tunnel, Enterprise, enterprise mobility, Hotfix, IKEv2, MFA, Mobility, Multifactor Authentiction, network policy server, NPS, Operational Support, PKI, Remote Access, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Security, TPM, Trusted Platform Module, Update, user tunnel, VPN, Windows 10
Tagged , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 7, 2020

https://directaccess.richardhicks.com/2020/09/07/always-on-vpn-updates-for-windows-10-2004/

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

13 Comments
by Richard M. Hicks on November 18, 2019  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, device tunnel, enterprise mobility, High Availability, Hotfix, IKEv2, Kemp, Load Balancing, LoadMaster, Mobility, Remote Access, routing and remote access service, RRAS, troubleshooting, Update, user tunnel, VPN, Windows 10, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 18, 2019

https://directaccess.richardhicks.com/2019/11/18/always-on-vpn-ikev2-load-balancing-issue-with-kemp-loadmaster/

Always On VPN DNS Registration Update Available

Always On VPN DNS Registration Update AvailableWhen configuring Always On VPN, administrators have the option to enable DNS registration for VPN clients. When this option is set, VPN clients will register the IP address assigned to their VPN interface in the internal DNS. This allows client devices to be managed using their hostname from the internal network whenever they are connected remotely.

DNS Registration

DNS registration is enabled in one of two ways, depending on how Always On VPN client devices are managed.

Intune

When using the native Microsoft Intune UI to manage Always On VPN profiles, DNS registration can be configured by selecting Enabled next to Register IP addresses with internal DNS in the Base VPN settings section.

Always On VPN DNS Registration Update Available

ProfileXML

When using custom ProfileXML with PowerShell, SCCM, or Intune, the administrator will define the RegisterDNS element to enable DNS registration.

Always On VPN DNS Registration Update Available

Known Issues

Some users have reported unexpected behavior when DNS registration is enabled. Specifically, under some circumstances the VPN client will register the IP address of the VPN network interface along with the IP address of its public network interface (Wi-Fi, Ethernet, etc.). However, the VPN client can only be managed using the VPN interface. If the VPN client’s hostname resolves to its public IP address, manage out will fail.

This appears to happen only when Name Resolution Policy Table (NRPT) rules are defined in Intune DNS settings, or if the DomainNameInformation element is defined in ProfileXML.

Always On VPN DNS Registration Update AvailableAlways On VPN DNS Registration Update Available

Resolution

Microsoft recently released fixes for this DNS registration issue for Windows 10. The fix for this issue is included in the following updates.

Windows 10 1803 – KB4507466
Windows 10 1809 – KB4505658
Windows 10 1903 – KB4505903

Additional Configuration

After installing the update, the following registry entry must be defined on each VPN client.

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 1

To enable this setting, open an elevated PowerShell window and run the following command.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\’ -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force

Once complete, restart the client device for the changes to take effect. After validation testing is complete, the registry entry can be deployed to Always On VPN clients using Active Directory group policy preferences or Intune.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Updates to Improve Connection Reliability

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes

75 Comments
by Richard M. Hicks on August 5, 2019  •  Permalink
Posted in Always On VPN, AOVPN, Device Management, device tunnel, DNS, Enterprise, enterprise mobility, InTune, Manage Out, Microsoft Intune, Mobility, name resolution policy table, NRPT, PowerShell, ProfileXML, Remote Access, routing and remote access service, RRAS, systems management, Update, VPN, Windows 10
Tagged , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 5, 2019

https://directaccess.richardhicks.com/2019/08/05/always-on-vpn-dns-registration-update-available/

Always On VPN RasMan Errors in Windows 10 1903

Always On VPN RasMan Errors in Windows 10 1903After deploying or upgrading to Windows 10 1903, administrators may find that Windows 10 Always On VPN connections fail to establish successfully. Always On VPN connections continue to work for Windows 10 1809 and earlier clients, however.

Important Note: The issue described in this article has been addressed in KB4505903 (build 18362.267) released July 26, 2019.

RasMan Event Log Errors

When this occurs, the application event log contains an error with Event ID 1000 that includes the following information.

“Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005”

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Root Cause

RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix.

Workaround

As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell.

Group Policy

Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps.

1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds
2. Double-click Allow Telemetry.
3. Select Enabled.
4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security).
5. Click Ok.

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Registry

Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting.

HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1

Always On VPN RasMan Errors in Windows 10 1903 Administrators may find that Windows 10 Always On VPN connections fail after deploying or upgrading to Windows 10 1903. Always On VPN connections continue to work for Windows 10 1809 and earlier clients. RasMan Event Log Errors When this occurs, the application event log contains an error with Event ID 1000 that includes the following information. “Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, and “Exception code: 0xc0000005” Root Cause RasMan failures can occur in Windows 10 1903 clients when telemetry is disabled via group policy or the registry. Microsoft has identified the issue and is currently working on a fix. Workaround As a temporary workaround to restore Always On VPN connectivity, enable telemetry on Windows 10 1903 using Active Directory or local group policy, the local registry, or PowerShell. Group Policy Create a new GPO or edit an existing one by opening the group policy management console (gpmc.msc) and performing the following steps. 1. Expand Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds 2. Double-Click Allow Telemetry. 3. Select Enabled. 4. Choose 1-Basic, 2-Enhanced, or 3-Full (do not select 0-Security). 5. Click Ok. Registry Telemetry can also be enabled locally by opening the registry editor (regedit.exe) and modifying the following registry setting. HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry DWORD = 1 Note: The AllowTelemetry value can be removed entirely, if desired. PowerShell PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting. New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely. Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\' -Name AllowTelemetry Restart Required Once these changes have been made, restart the client and test the Always On VPN connection. Additional Information asdf

Note: The AllowTelemetry value can be removed entirely, if desired.

PowerShell

PowerShell can also be used modify or remove the AllowTelemetry value on Windows 10 1903 clients. Run the following PowerShell command to update the AllowTelemetry setting.

New-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\’ -Name AllowTelemetry -PropertyType DWORD -Value 1 -Force

Optionally, run the following PowerShell command to remove the AllowTelemetry setting entirely.

Remove-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection\’ -Name AllowTelemetry

Service Restart Required

Once these changes have been made, restart the Remote Access Connection Manager service (RasMan) using the Services mnagement console (services.msc) or by running the following PowerShell command.

Restart-Service RasMan -PassThru

Optionally, the client can be rebooted to apply these changes.

Additional Information

Windows 10 1903 Known Issues

 

9 Comments
by Richard M. Hicks on July 1, 2019  •  Permalink
Posted in Always On VPN, AOVPN, enterprise mobility, Hotfix, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, Update, VPN, Windows 10
Tagged , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 1, 2019

https://directaccess.richardhicks.com/2019/07/01/always-on-vpn-rasman-errors-in-windows-10-1903/

Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated April 29, 2020 to resolve an issue where the DirectAccess RADIUS encryption certificate was not published to the DirectAccess Server Settings GPO in Active Directory.

When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.

Renew DirectAccess Self-Signed Certificates

Certificate Expiration

These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.

PowerShell Script on GitHub

The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.

Important Considerations

When the IP-HTTPS certificate is renewed using this script, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy. This will require connecting to the internal network locally or remotely using another VPN solution. The NLS and RADIUS encryption certificates can be updated without impacting remote users.

In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.

Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false

Additional Information

PowerShell Recommended Reading for DirectAccess Administrators

Top 5 DirectAccess Troubleshooting PowerShell Commands

 

 

66 Comments
by Richard M. Hicks on May 2, 2019  •  Permalink
Posted in authentication, certificates, DirectAccess, Encryption, enterprise mobility, GitHub, IP-HTTPS, IPv6 Transition, Mobility, name resolution policy table, PowerShell, Remote Access, Security, SSL, SSL and TLS, TLS, transition technology, troubleshooting, Update, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on May 2, 2019

https://directaccess.richardhicks.com/2019/05/02/renew-directaccess-self-signed-certificates/

Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

32 Comments
by Richard M. Hicks on April 17, 2019  •  Permalink
Posted in Always On VPN, AOVPN, Cisco, Cisco Umbrella, Cisco Umbrella Roaming Client, cloud, DNS, enterprise mobility, Hotfix, Mobility, NCSI, network connectivity status indicator, OpenDNS, PowerShell, public cloud, Remote Access, routing and remote access service, RRAS, Security, troubleshooting, Update, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 17, 2019

https://directaccess.richardhicks.com/2019/04/17/always-on-vpn-updates-to-improve-connection-reliability/

DirectAccess Inbox Accounting Database Optimization

DirectAccess Inbox Accounting Database OptimizationRecently I wrote about an issue with DirectAccess servers exhibiting high SQL Server CPU usage. In that article I demonstrated a way to resolve the issue by adding a crucial index to a table in the remote access inbox accounting database. The process was a bit involved and required downloading third-party tools to make configuration changes on the DirectAccess server.

Going forward, making these changes will now be much easier. Microsoft has published guidance for optimizing the remote access inbox accounting database using PowerShell. They’ve also provided scripts to back up the database and to confirm that optimization has been implemented.

For more information and to download the remote access inbox accounting database optimization PowerShell scripts, click here.

2 Comments
by Richard M. Hicks on March 21, 2016  •  Permalink
Posted in DirectAccess, Remote Access, Update, Windows Server 2012 R2
Tagged , , , , , , , ,

Posted by Richard M. Hicks on March 21, 2016

https://directaccess.richardhicks.com/2016/03/21/directaccess-inbox-accounting-database-optimization/

Windows 10 November Update Available Today

Windows 10 November Update Available TodayToday Microsoft announced the availability of the November Update (formerly Threshold 2) for Windows 10. With this update, Microsoft is now touting Windows 10 build 1511 as “enterprise ready”, with a number of key features and enhancements designed to drive enterprise adoption for the client operating system.

  • Performance Improvements – According to Microsoft, the Windows 10 November Update includes important improvements in performance, improving boot time almost 30% over Windows 7 installed on the same system.
  • Windows Update for Business – Windows Update for Business enables IT to control Windows update within their organization, allowing administrators to roll out updates on their schedule. New features with this service include creating device groups and enabling phased deployment of updates across the organization
  • Windows Store for Business – The Windows Store for Business provides IT with a mechanism to provision and manage apps for Windows 10 devices, both from the Windows Store and their own line-of-business apps.
  • Telemetry Control – Beginning with Windows 10 build 1511, enterprise customers will now have the ability to completely disable all Windows telemetry. Although not recommended, this feature is essential for many organizations to maintain the highest levels of security.

Since Windows 10’s release in late July of this year, enterprise customers have deployed Windows 10 on more than 12 million business PCs. Many organizations who have not yet upgraded are in the planning and pilot stages today, or will be soon. The enterprise adoption rate for Windows 10 continues to accelerate, and no doubt will do so even more with the release of Windows 10 build 1511.

Don’t forget that Windows 10 already includes a number of important security advancements such as Credential Guard to mitigate various credential theft attacks, Device Guard to prevent installation of malicious software, and Windows Hello to strengthen authentication with the use of biometrics. These features, along with the new capabilities and services introduced today, continue to make Windows 10 a compelling client operating system in the enterprise.

Of course the perfect complement to Windows 10 in the enterprise is DirectAccess. To learn more about how to maximize your investment in Windows 10 with DirectAccess, here are some essential references.

In addition, DirectAccess consulting services are also available. More details here.

4 Comments
by Richard M. Hicks on November 12, 2015  •  Permalink
Posted in Remote Access, Update, Windows 10, Windows Server 2012 R2
Tagged , , , , , , ,

Posted by Richard M. Hicks on November 12, 2015

https://directaccess.richardhicks.com/2015/11/12/windows-10-november-update-available-today/

DirectAccess Client and Server Settings GPOs Deleted

Microsoft Windows Server Active DirectoryFor DirectAccess deployments where domain controllers are running Windows Server 2003 or Windows Server 2003 R2 using the File Replication Service (FRS) for replication, DirectAccess client and server settings Group Policy Objects (GPOs) may be deleted. If these GPOs are deleted, DirectAccess connectivity will be disrupted. If the GPOs cannot be recovered via backup, it will be necessary to rebuild the entire DirectAccess deployment from scratch.

Microsoft recently updated their DirectAccess Unsupported Configurations documentation to reflect new guidance for DirectAccess deployments where the FRS is used for the distribution of Active Directory GPOs. DirectAccess is no longer supported in environments where FRS is used for SYSVOL replication.

What this means is that if you plan to deploy DirectAccess, domain controllers must be running Windows Server 2008 or later, and Distributed File System Replication (DFS-R) must be used for replication.

More details can be found here.

4 Comments
by Richard M. Hicks on July 27, 2015  •  Permalink
Posted in DirectAccess, Remote Access, Update, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 27, 2015

https://directaccess.richardhicks.com/2015/07/27/directaccess-client-and-server-settings-gpos-deleted/

Hotfix Available for DirectAccess OTP Configuration Issues

If you’ve ever tried configuring DirectAccess to use One-Time Password (OTP) authentication, you’ve no doubt discovered that the native Microsoft Remote Access Management console would return the following error when trying to detect and locate Certificate Authority (CA) servers.

No CA servers can be detected, and OTP cannot be configured. Ensure that
servers added to the list are available on each domain controller in the
corporate network.

Configure DirectAccess with OTP Authentication

The workaround for this issue required dropping to the command line and executing PowerShell commands to complete this configuration as I outlined here.

Thankfully Microsoft has made available a hotfix to address this issue, returning full GUI functionality for configuring DirectAccess and OTP authentication. For additional details about this hotfix and to request the update itself, click here.

3 Comments
by Richard M. Hicks on April 23, 2015  •  Permalink
Posted in DirectAccess, Hotfix, PowerShell, Remote Access, Update, Windows Server 2012 R2
Tagged , , , , , , , ,

Posted by Richard M. Hicks on April 23, 2015

https://directaccess.richardhicks.com/2015/04/23/hotfix-available-for-directaccess-otp-configuration-issues/

« Older Posts
%d bloggers like this: