Datastores not listed after deploying VMware Replication Appliance

Just did a fresh deployment of the VRM 6.5.1 appliance into vCenter 6.5.1u1 which controls our vSphere 5.5 hosts.

Installation and configuration went smoothly but when I went to setup a test replication for a VM I could not complete the setup because none of my datastores were being listed.

A reboot of vCenter did not help.

Restarting the VRM service via the appliances WebUI fixed the problem. A reboot of the appliance would have also probably worked.

You can restart the service via: https://<APPLIANCE FQDN>:5480/

  1. Click ‘Configuration’ under the ‘VM’ page
  2. Click ‘Restart’ at the bottom

Pretty straight forward solution but I didn’t find this in the first few pages of Google results. Might save someone else a bunch of troubleshooting.

Some users cannot login to new NPS based VPN server

Our environment previous used a Windows 2003 Server running RAS to offer our employees VPN. This server went away for multiple reasons and we built a brand new 2012 R2 server running NPS and RAS.

Since switching over we’ve had a few employees unable to login to the new VPN server. They keep getting “Invalid Username/Password”. Strangely these users had access to a different account that would work from their personal device. This eliminated client side issues as being the culprit.

Checking the Event Logs on the VPN server we found this event:

We had the user login to Webmail to verify their username and password. Everything was fine.

That led us into the text based logs. We found these:

The tip-off here was “Microsoft Routing and Remote Access Service Policy”. That was not the name of our VPN access policy. In fact that policy is located on a completely separate tab in NPS.

Turns out the issue was a AD account setting:

After some digging I found out that this AD attribute is called ‘msnpallowdialin’ and can have the following values:

Knowing this I wrote a quick PowerShell script to tell me how many accounts we had configured incorrectly:

Turns out we had 142 accounts that were incorrect and 1783 accounts that were. All of the accounts that were incorrect have been around a LONG time.

To change this property on all accounts that were set to TRUE or FALSE we used the following script:

I didn’t bother making variables of the repeating values. You can just search/replace these scripts. You need to change “OU=<OU>,OU=<OU>,DC=DOMAIN,DC=FQDN” to be the OU of where your users are and “<DC FQDN>” to the FQDN of one of your Domain Controllers.

Powershell script to report on total send/received e-mails in Exchange v2.0

An updated and improved version of my old script from here.

This script has been tested against Exchange 2016 CU4. I do not know if it will work against older versions of Exchange.

The script can be configured to run as a scheduled task and it generates a e-mail report of users who have sent more than ‘x’ e-mails so far today or the previous day.

You can now exclude specific e-mails from the report by placing them in the ‘exceptionList.txt’ file which is created after the scripts first run

We use this script to find compromised accounts that are blasting out spam.



DFS not working properly over VPN for personal computers

We recently switched to a new VPN server after Mac OS dropped support for PPTP and because we were way overdue to do it anyway. Since then personal computers were unable to access network shares via DFS.

They could go directly to the file server and that would work.

Users who connected to VPN with a organization owned laptops were able to use DFS.

After some digging it turned out the issue was our old VPN allowed for WINS (yes yes I know) and our new VPN has WINS disabled (by design, see… we’re trying)

The proper solution to this problem is to re-configure DFS to use DNS only:

Unfortunately I didn’t have the time to implement this.

What we ended up doing is re-configured the DHCP scope to set VPN users DNS Suffix to ‘’

I then added aliases for all of our file servers and DFS servers under ‘’. Example:

  •, CNAME,
  •, CNAME,

This is a crappy hacky work around that isn’t really sustainable but will work for now until we can sit down and plan changing our DFS over to use DNS only.

Domain Computers worked fine because we use group policy to push out multiple DNS search suffixes. DHCP doesn’t allow you to do this with Windows PCs so when they try to lookup ‘fileserver1’ they would try to hit WINS if implemented and then append their DNS suffix ( and then fail to find the file server resulting in a “Network Path Not Found” errors.

Error 500 when downloading/accessing OAB in Exchange 2016

We’ve just finished migrating all of our users from a legacy AD forest with Exchange 2010 into a whole new AD forest with Exchange 2016.

During the initial deployment of Exchange 2016 a new mailbox store was created, the existing system mailboxes were migrated (mailbox move) to the new store and the default Exchange 2016 store was deleted. We think our OAB broke at this point.

The behavior we were seeing was Outlook clients perpetually saying “Updating Address Book”, slow performance in Outlook where previously there wasn’t, delayed e-mail coming into mailboxes.

If users went into “C:\Users\%username%\AppData\Local\Microsoft\Outlook\Offline Address Books” they either had nothing or a old copy from our previous Exchange 2010 deployment. If they closed Outlook, purged the contents of “Offline Address Books” they would never be re-created because the OAB would never download from Exchange.

I’m assuming you’ve got everything else configured correctly on your end at this point. Things like Internal/External URLs, SSL certificates, yadda.

First thing first was to check if the OAB was on Exchange (I’ve redacted some information with *’s):

The lines that mattered here to me were:

  • Guid
  • LastTouchedTime

As you can see this OAB has never been touched which means to me it’s never been updated or created.

Using the GUID I checked to see what IIS had to say about the OAB:


Loading this URL prompted me for a login, good so far, entered my domain credentials and got this error:

After this I manually checked each of our Exchange servers (we have 3) to see if they all gave the exact same Error 500. They did:


During my Googling for this I found this blog post:

The permissions were incorrect on our web.config file so I tried the suggested fix in the blog post. It didn’t work.

I then went through this document: and made all of the tweaks needed to match those recommendations. I couldn’t find a Exchange 2016 specific document but there weren’t many tweaks to be made and they all made sense to me.

This did not resolve the issue either.

Next up was a Outlook Web Services health check using this PowerShell command:

Ok. Error 500. We know this already.

On my local system I ran this command in Command Prompt:

After digging around the file system of our Exchange servers I was unable to find a folder called 28a57cb5-b2c8-442a-81f3-a48a05f9ab7b in the following locations:

  • C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\oab

This confirmed for me that the OAB wasn’t even being generated.

We then tried manually updating the OAB. The command succeeded but no OAB was generated.

We think what happened is the moving of the System Mailboxes way back at the beginning of our Exchange 2016 deployment broke the association of which system mailbox generates the OAB.

Running this command confirmed that there was no mailbox assigned to generate the OAB:

To fix the problem we did the following:

Enabled Global Distribution of the OAB (since we have 3 Exchange Servers why let one of them have all the fun?):

Then we created a new system mailbox dedicated to the purpose of generating the OAB and manually regenerated the OAB. We put the account in the same Domain as Exchange instead of where the users are:

It took all of 30 seconds and then the OAB URLs started working again and displaying a properly formatted XML file. Outlook clients automatically started downloading the OAB with no issues.

Checking our OAB:

The LastTouchedTime was now set. I’ll be checking again tomorrow to make sure the LastTouchedTime changes based on the Schedule.

Re-running this command confirmed there was now an account set to generate the OAB:

Re-running the OutlookWebServices test shows a successful OAB check:

Finally the event viewer on our Exchange server should also show Event ID 17001 and 17002 for the MSExchange Mailbox Assistants Provider showing the start and completion of the OAB generation: