Exchange permission issues for a single user on a generic mailbox

We created a new generic mailbox in Exchange 2010. Created a group (Global) and added the users to it. We then created a Universal group, added the Global group to it and then added the Universal group to the mailbox with full mailbox permissions.

After the obligatory wait 24 hours for Exchange to update it’s permissions 4 of the 5 users in the Global group had access to the generic mailbox. The 5th user could not access the mailbox via their Outlook or Webmail. Permission denied errors.

We tried removing/re-adding them from the group with no success. We tried migrating their mailbox back and forth with no success.

Finally after some digging we thing we figured out the problem.

The user in question had originally been migrated from Exchange 2003 to 2010. Then at some point while on Exchange 2010 we had to purge/re-create their Mailbox.

The process of purging re-creating their mailbox changed their LegacyDN to the new, correct, format for Exchange 2010 and dumped their old Exchange 2003 LegacyDN.

To view a users legacy DN run the following Powershell command:

What we ended up doing is re-creating their LegacyDN from Exchange 2003 as a new X500 record and then they were instantly able to access the generic mailbox.

It could always be coincidence…..

References:

Networking randomly dies on a 2012 R2 vSphere VM

Strange issue. Simple solution.

We had a Windows Server 2012 R2 Domain Controller sitting on vSphere 5.5 (2068190) which would randomly lose it’s network connection.

When you logged into the system locally the network interface appeared to be up but you could not connect to anything outside of the VM.

If I rebooted the VM it would work for a few hours or less and then the network would drop out again.

Digging through the event viewer I came across these:

The VM had a E1000 NIC attached to it. I figured the issue was the VM NIC model and got some backup to my theory from here: https://community.spiceworks.com/topic/504405-windows-server-2012-r2-guest-os-on-vmware-keeps-losing-gateway-connection

The solution appears to have been removing the E1000 NIC and adding either a E1000E NIC or in my case a VMXNET 3 NIC.

Previous version of the Active Directory Replication Status Tool

Who liked using the Active Directory Replication Status Tool? I did.

Who thought it was a great, simple, straight forward tool that was far easier than interpreting the output of some command line tools and didn’t feel it needed to become a cloud service with a less intitive interface? I do.

Digging through a few of my servers I found the old installer for the Active Directory Replication Status Tool. The version you can install on your own servers and doesn’t appear to give an error about the installer being expired.

Download it here: https://dl.dropboxusercontent.com/u/22772464/adreplstatusInstaller.zip

I believe this is version 1.1 even though the splash page when launching it says it’s 1.0. It was the latest version you could download before Microsoft expired it here and told everyone to start using the cloud based SCOM solution they offer.

Please share it/mirror it for all to enjoy.

 

Update – 2016-04-05

Looks like Microsoft is trying to kill this tool. When you try the use the version I’ve linked above now it says it has also expired.

I’ve figured out a workaround. Download this handy tool and then do this:

runasdate settings

If anyone knows assembler and wants to try dissecting repl.exe to remove the date check I’ll happily link/host to their modified repl.exe.

I’ve seen a few comments on other sites about the saftey of getting this tool from a non-Microsoft source and this is the best I can provide to prove I have not altered the MSI file. If you check the hashes against the two download links below you’ll see they match files uploaded well before this blog post.

MSI File
MD5: d63ceaa4131f8dc64800d33ac3b242c7
SHA1: 1a117510e42d284199743c53722dd51690a93d59

http://www.herdprotect.com/adreplstatusinstaller.msi-1a117510e42d284199743c53722dd51690a93d59.aspx
https://malwr.com/analysis/Y2JlNDQ0YmM0MjM3NGY4MWJlOGJhOTkyMDNkZGQxZGI/

You can try the workaround I’ve mentioned above on the official download as well: https://www.microsoft.com/en-ca/download/details.aspx?id=30005

 

Update 2016-04-20

Good news everyone! Microsoft has brought back the stand-alone tool thanks to everyone who provided them feedback demanding it.

See: https://feedback.azure.com/forums/267889-operational-insights/suggestions/12293631-bring-back-the-on-prem-ad-replication-status-tool

The new, non-expiring download, can be found here: https://www.microsoft.com/en-us/download/details.aspx?id=30005

Powershell script to monitor mount points in Windows and e-mail an alert

Simple script inspired by this blog post.

This script will read a servers.txt file located in the same directory as the script, check each server listed (one per line, use the servers FQDN) for mount points, see how much free space is available, compare it to a minimum amount you set and then e-mail an alert if below the minimum amount.

Should work on Windows Server 2008 and newer. Might work on Server 2003 but I haven’t tested it.

 

Error 1603 while upgrading vCenter 5.5 to 6.0u1

Upgrading vCenter recently from vCenter 5.5 to 60.u1 and the upgrade would consistently fail displaying two error messages.

First it would display “An error occurred while invoking external command: ‘Database instance not defined for mssql provider'”

Then the installation would appear to proceed until it got to installing the VCSServiceManager. Then I would get Error 1603 saying that it couldn’t talk to the database server.

We run our vCenter Server database off a separate MSSQL 2012 Standard server.

I found plenty of resources on VMware’s site for this error:

None of these solved the issue for us.

Some how I ended up on this article: Installing or Upgrading to vCenter Server 6.0 fails with the error: Unable to get port number for mssql provider (2125492)

That isn’t the error we were getting but the solution ended up fixing the problem for us.

We had been using most of those special characters in the password for the vCenter user accessing our MSSQL Server.

I changed the password to something that didn’t have those special characters on the MSSQL server and then did the following to update the password in vCenter:

  1. Change the MSSQL users password
  2. Updating the database user password stored in vCenter Server (2000493)
  3. Updated the password in the ODBC connector
  4. Restarted the VMware vCenter Server service

The upgrade was successful after that.

Note: My upgrades were getting far enough to completely remove the existing installation of vCenter 5.5 but not far enough to alter the database. I had to revert my vCenter VM to my pre-upgrade Snapshot so vCenter 5.5 was back up and running before I could change the password.