Ping "General Failure" Intermittent Issue (vSphere 5.0 VM, Port Group, EST) Multi-Homed RRAS on Windows Server 2012 R2

There are intermittent issues with your Windows Server 2012 R2 VM, with Routing and Remote Access installed. The VM is running on vSphere v5.0 and it is connected to a Port Group, connected to a dedicated vSwitch. Extensible Switch Tagging (EST) is in place therefore the physical switch stack is doing all the VLAN tagging.

The network interface are configured to support a multi-homed RRAS server to provide L2TP/IPsec VPN to clients, one interface is external which is configured behind a Cisco ASA firewall. Due to L2TP/IPsec being utilized NAT-T is configured to forward external traffic to this interface. The internal interface is connected to the Production subnet.

When the server is booted, you can ping resources both internal and external without issue, if you use the ping 8.8.8.8 -t command to send continuous ICMP packets, it begins to fail with General Failure.

 

It turned out to be, and you guest it an issue with Microsoft Routing and Remote Access. The fix was to disable the Inbound and Outbound Filters, although this may seem to be a security risk in this instance the RRAS server is behind a Cisco ASA Firewall therefore the software filters on RRAS are not required.

To disable the filters expand IPv4 and General, then right click on each of the interfaces and select Properties.

Click Inbound Filters...

 

Click Receive all packets except those that meet the crtieria below click OK to commit the changes.

 

Do the same for the Outbound Filters but ensure Transmit all packets except those that meet the criteria below, again click OK.

 

Now if you attempt to try the ping the resources both externally and internally you will probably find it now works successfully. Yet another fix that would encourage you to deploy a proper hardware VPN concentrator such as a Cisco ASA, Juniper, NetScaler etc.

 

 

 

 

DirectAccess Client Troubleshooting Tool "Failed to Connect to HTTP Probe at http://DirectAccess-WebProbeHost.Domain.local" User Tunnel Tests

DirectAccess is deployed in your environment, your client is reporting to be "Connecting" but you can see the machine connected from the Remote Access Management console. This is probably because the Infrastructure tunnel has successfully been established but the User Tunnel has failed to come up. When you run the DirectAccess Client Troubleshooting Tool the User Tunnel Tests fail with the error;

Failed to connect to HTTP probe at http://DirectAccess-WebProbeHost.domain.local

You try and ping DirectAccess-WebProbeHost from the DirectAccess server with no success, this is off course because the (A) record for DirectAccess-WebProbeHost has either not been created or it has been removed. It is my personal preference to use PING for the Network Connectivity Assistant (this is what the Web Probe host is referred to from the DirectAccess interface).

The solution is;

Open DNS from a Domain Controller.

Create a new (A) record in the Domain's Forward Lookup Zone something like DaWebProbeHost and point this to a server that will always be online.

Open the Remote Access Management console from the DirectAccess server, click Step 1 Remote Clients

Click Network Connectivity Assistant, the current entry will be set to HTTP DirectAccess-WebProbeHost this is the default value that the Getting Started Wizard configured. Delete this entry.

 

Right click on the * and select New

Select the connect type to PING and type the FQDN of the DAWebProbe you configured by creating the (A) record in DNS. Click Validate.

 

Now if you force replication between all your Domain Controllers and perform a gpupdate /force on the client, when you reconnect to the internet and run the DirectAccess Troubleshooting Tool you will now find the User Tunnel Tests are now reporting no errors.

DirectAccess GPO's Error "Required GPO Permissions" not Enterprise Admin

You are deploying DirectAccess in a multi-domain, single forest environment. Clients and users reside in one domain, and the DirectAccess Servers in another. Both domains have two way trusts. The forest root domain is separate to these domains and hosts the Schema Master and the Domain Naming master FSMO role.

When you run the DirectAccess wizard and are about to commit changes to the GPO's you receive the error "Required GPO Permissions" on the client settings GPO.

 

The cause here is that the user account provisioning DirectAccess is not a member of the Enterprise Admins forest wide group. Simply add the user account to the Enterprise Admins group, or log in with an elevated account that natively has this level of access. By default the Enterprise Admins group has Full Control access to all of the domain in the forest therefore it is advisable to limit membership.

 

When you try to re-run the wizard with the correct credentials it should not allow you to continue.

 

Microsoft RRAS VPN "Error 741: The local computer does not support the required data encryption type" while configured with GPO

Although not my first choice for a remote access solution, Microsoft RRAS throws the error "Error 741: The local computer does not support the required data encryption type" when you try to initiate connection configured via GPO's over L2TP/IPsec.

 

This was down to a mismatch in the settings configured in the GPO, on the Security tab of the IPsec interface the Data Encryption setting was set to No encryption allowed (server will disconnect if it requires encryption).

 

Although the options inside the Group Policy Preferences are not listed word for word the same, on the Security tab, under Advanced (custom settings) should be set to Required.

 

 

Use gpupdate /force to refresh the settings and attempt to create a connection again.

 

 

Configuring Database Availability Group (DAG) in Exchange 2013 SP1

In this example I have two Mailbox Servers, and two Client Access Servers. I am going to configure a Database Availability Group. The official Microsoft description of a DAG, borrowed from TechNet.

 

 

DAG's work by replicating Mailbox Databases to neighbouring Mailbox Servers, deployed correctly this can create a highly resilient Exchange environment. Although Replication traffic can share the traditional MAPI network, it is considered best practise to separate the Replication traffic do it own network, either a subnet and/or VLAN.

 

I have provisioned my Mailbox Severs with two network adapters to support this configuration. It is important to name the adapters descriptively, as by default Exchange 2013 automatically configures the separate Replication network.

 

My adapters have been renamed Domain and Replication. The Domain interface is on the 192.168.1.0/24 subnet which is my production subnet that contains Domain Controllers, SCCM etc. The Replication interface is configured on the 196.100.10.0/24 subnet.

 

 

The Domain interface should be configured like it would on any other server, although as a Windows computer can only have a single default route (Default Gateway) the Replication interface should not be configured with a Gateway.

 

 

Click on the Advanced... button from the Internet Protocol Version 4 (TCP/IPv4) Properties page, and select the DNS tab. Untick the Register this connection's addresses in DNS.

 

 

As the Replication interface does not have a default gateway, a static route is required to provide a route to the rest of the subnet. The route add subnet mask subnetmask interface -p command to add this route. The -p switch ensures the route is persistent.

 

 

You can perform a route print to display the routing table on the server.

 

 

You will run into issues when creating the DAG, and adding DAG members if the bind order is not configured correctly. It is important the Domain interface is the primary connection.

 

 

The DAG itself must be represented in Active Directory, by the way of a Cluster Name Object. This is done by creating a disabled computer object. To do this open Active Directory Users and Computers, right click and select New, Computer name this object according. Please note when creating the DAG it must be named the same as the object.

 

 

As mentioned previously it's important the DAG computer object is disabled.

 

 

The security principal Exchange Trusted Subsystem is added to the ACL of the Cluster Name Object. It must also have Full Control access to this object. You can do this by using the Security tab on the properties of the object.

 

 

Now open the Exchange ECP and click Servers, Database Availability Groups. Click the + symbol to create a new DAG.

 

 

Now populate the fields with the corresponding information. Notice my mistake here, that will cause this to fail. My DAG is not named exactly the same as the Cluster Name Object, please ensure this is done properly. The File Share Witness is used as a tie breaker if servers suffer failure, if you do not specify a Witness server the wizard will automatically create it on one of the Client Access Servers. If you choose to configure your own File Share Witness, the Exchange Trusted Subsystem security principal must be in the local Administrators group of the server that is going to host the File Share. You will notice a Domain Controller cannot be a File Share Witness because DC's do not have local users and groups.

 

A DAG must also have an IP address, it is my recommendation to make this a static address even though the option is there to have DHCP assign an address dynamically.

 

 

Click Save and the DAG is created.

 

 

Now you must add DAG members to the DAG, this is done using the Add DAG Member button.

 

 

Click the + to add servers.

 

Select the Mailbox Servers you want to be part of the DAG, click Add and OK.

 

 

Click Save to commit the configuration.

 

 

 

By default Exchange automatically detects and configures the MAPI and Replication networks, there is not an obvious place in the GUI to show the MAP and Replication networks configuration. The PowerShell command Get-DatabaseAvailabilityGroupNetworks this shows how Exchange has configured the networking.

 

 

Now the DAG is created, with DAG members you must now configure Database Copies on the individual Mailbox Databases you want to be replicated by the DAG.

 

Click the ... icon and select Add Database Copy.

 

 

 

 

Specify the Mailbox Server you would like the Database replicated to. The Preference number is used to define a preference of where the database should be mounted while the DAG is operating normally. Click Save.

 

 

The wizard will now replicate the initial copy to the new DAG member server.

 

 

The Active button can be used when a server is selected to gracefully manage the failing over of what server is currently hosting the Mailbox Database. The Activate button will mount the Database on another DAG member and automatically redirect all connection, and it will also manage the reverse of the replication traffic. This can be useful if a server hosting a Mailbox Database requires updating or patching.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Exchange 2013: Error: "The authentication service is unknown" when adding Mailbox Server to DAG

When you are adding Mailbox Server's to an existing DAG the interface throws the very unhelpful error "The authentication services is unknown". In my environment I have a dedicated Replication network for DAG traffic, and the fix for me was to make sure the bind order was set to MAPI network first, ensuring the Replication network was last.

 

 

Rebooted the Mailbox Servers was good measure, tried again and it worked.

Exchange 2013: Adding Mailbox Servers to existing DAG - Error "A server-side database availability group administrative operation failed with a transient error. Please try the operation again"

When you are in the process of creating a DAG, the process halts and returns the error "A server-side database availability group administrative operation failed with a transient error. Please try the operation again"

 

 

The clue is in the last part of the error "The fully qualified domain name for node "DAG" could not be found" this error is caused because the Cluster Name Object has not been pre created in Active Directory or alternatively the name of the Cluster Name Object computer account does not match the name of the DAG you are trying to add these computers to.

 

 

 

 

Exchange 2013: "error Access Denied The operation was'nt successful because an error was encourntered" when creating a DAG

When you try to create a Database Availability Group (DAG) with the Exchange 2013 web-GUI, the interface throws the following error "error Access Denied The operation wasn't successful because an error was encountered"

 

 

This was because the target machine you have elected to be your File Share Witness must have the Exchange Trusted Subsystem group in it's local Administrators group, simply add it to the group and the DAG will successfully create.

 

This off course creates a problem if you are trying to install the File Share Witness on a Domain Controller, as DC's do not have any local users or group you simply cannot add the Exchange Trusted Subsystem group into the local Administrators. Therefore meaning the File Share Witness cannot be hosted on a DC.

Customizing the WinPE Environment for the Microsoft Deployment Toolkit (MDT) 2013

The Microsoft Deployment Toolkit (MDT) is a solutions accelerator from Microsoft to aid operating system deployment, MDT offers a subset of SCCM deployment features.

MDT uses Task Sequences to deploy and configure operating systems and applications. WinPE with Windows 8 and MDT 2013 is WinPE v5.0. In this post I will document how you can customise the default WinPE environment.

 

Customising the "IT Organization" field.

 

To edit the "IT Organization" field, you must make a change to the CustomSettings.ini file that is installed as part of the Deployment Share. The CustomSetting.ini file can be found at C:\DeploymentShare\Control\, right click on the file and select "Edit".

Add "_SMSTSORGNAME=organization name" below the [Default] container.

 

After making any changes to the MDT Deployment Share, you must always update the content. This can be done by right click on the Deployment Share and selecting "Update Deployment Share".

 

You can also edit the "Running: " field on the Installation Progress box, I have found it good practice to change this to something descriptive, such as "Windows 8.1 Proof of Concept Project - May 2014".

This must also be done from the CustomSetting.ini file, if you have follow above and already customized the "IT Organization" field your CustomSettings.ini file should look like my one below.

Again it is important to update the Deployment Share so that MDT registers the changes and re-reads the CustomSettings.ini file.

 

It is also possible to change the WinPE background, I personally always like to change this to some kind of company branding, to do this you must have a suitable wallpaper in Bitmap format.

You must first right click on the Deployment Share and select "Properties"

Click on the "Windows PE" tab from the "Properties" window, in this example I am only customizing the x64 WinPE environment therefore this may be slightly different for your environment, therefore select either x86 or x64 from the "Platform" drop down.

I always copy my desktop wallpaper files to C:\Windows\Web\Wallpaper, therefore in this example I have pointed to my WinPE wallpaper Bitmap that is stored in the C:\Windows\Web\Wallpaper folder.

Click "Apply" and "OK".

Updating the Deployment Share will take a few minutes after changing the Wallpaper, this is because MDT has to insert the Wallpaper file into the Litetouch_x86 and Litetouch_x64 ISO files.

                                       

Click "Finish".