The reason why you’re encountering this error is because the account of user’s mailbox you’re trying to move does not have the property: Include inheritable permissions from this object’s parent enabled. This is not the default configuration of user objects in the domain but I find that a lot of applications or administrators tend to deselect this option when trying to achieve customized settings for the user accounts in their environment. To correct this, simply open up Active Directory Users and Computers and turn on the Advanced Features as shown here:

Once the Advanced Features is enabled, search for the user account you have this problem with:

… open up the properties of this object:

Navigate to the Security tab of the user object’s property and click on the Advanced button:

Notice in the following screenshot that Include inheritable permissions from this object’s parent is not enabled:

Simply enable this property as such:

Once this property is enabled, you should now be able to move the mailbox. This manual process works well if you only have a few accounts to modify but if you have hundreds or even thousands, a script may be a better option. Unfortunately, I did quite a bit of searches on the internet but was unable to find one that works.

Through the migrations from Exchange Server 2003 to 2010 I’ve done in the past, I’ve never ran into a problem I encountered over this weekend and while it looks like it’s quite common, I figure I’d blog about it anyways so I can reference my own notes in the future.

Problem

You attempt to move a mailbox from Exchange Server 2003 to 2010 but the process fails with the following error:

If you only have one or two accounts that have this problem, you can easily fix this by remove the user’s leading or trailing white space by editing the properties. If you have more than one of these accounts, you can use the solution as described in the blog post I mentioned above.

In Exchange Server 2003, it wasn’t quite as easy to redirect a user who types https://webmail.someDomain.com/ to https://webmail.someDomain.com/exchange as you were required to user a .asp page to redirect the requests to the root over to the /exchange directory. In Exchange Server 2010, this process has been simplified through a simple text and check box in IIS 7 (http://technet.microsoft.com/en-us/library/aa998359.aspx). You can find the instructions here but in case someone is looking for a screenshot of what the configuration looks like see the following:

Make sure you select the Only redirect requests to content in this directory (not subdirectories) as the redirect will not work without that checkbox enabled (I made the mistake while configuring this wondering why it didn’t work).

The cause is actually quite simple and it’s because you have, say, a 2-link policy set for your chassis discovery policy but you only have 1 link plugged in between your IOM and the fabric interconnects:

Note that an error won’t get thrown if you have, say, a 1-link policy set but you have 4 links plugged in so in this case, since we only have 1 cable plugged in from the IOM to the fabric interconnects, changing the policy to 1 link will fix the problem.

I had to update a Cisco UCS B series infrastructure two weeks ago from 1.3 to 1.4 and while going through the usual drill, I was prompted with the following warning message:

The firmware of the following components cannot be updated because they are using host/management firmware policy

As the client looked over and asked me what we should do, I realized that as seemingly obvious the warning message may be in suggesting that you should either:

1. Skip the firmware update on these interface cards

2. Remove your existing firmware policy

… you tend to stop and think about your next steps.

I have to admit that being someone who works on projects, most of my UCS work is greenfield deployments which means whenever I’m upgrading firmware, there’s not much to worry about going wrong. Yes, I do get called for break/fix issues but I’ve always told people who are in operations and actually maintain their UCS infrastructure that they probably know much more than I do when it comes to working with production environments.

Now that I’ve digressed way off topic, I almost always choose option #2 which means I need to go to each blade and remove the firmware policy applied to it. So the next question I got asked by the client was whether this would strip away the existing firmware or cause the blade to reboot. The answer is actually no. You can safely navigate to the blade’s policy tab to remove the policy then continue to update the adapters.

One of the projects I was involved in a month ago had several Cisco UCS C460 M1 servers that required a bare metal Windows Server 2008 install so as I began the process of installing the operating system, I also took the opportunity to screenshot the process. With that being said, though there’s nothing really special about this post, its main purpose is to demonstrate what the process looks like with the Cisco UCS Server Configuration Utility.

I prefer to use the CIMC for the install instead of the console because I usually fire up a few instances for different servers which will allow me to do simultaneous installs:

Mount the Cisco UCS Server Configuration Utility ISO:

Reboot the server:

With the Cisco UCS Server Configuration Utility mounted, you’ll see it boot into the utility:

Accept the EULA as we always do:

As shown in the screenshot below, you can see a brief summary of the server information:

If you proceed to the OS Install menu and attempt to immediately start the installation of the operating system without configuring the hard disks’ RAID level, you’ll see something like this:

If that’s the case, then proceed to configure the disks’ RAID by navigating to Server Configuration –> RAID Configuration:

I won’t go into too much detail since the screenshots are pretty self explanatory so to summarize, I’m configuring 2 sets of RAID-1 and 1 hotspare:

Now that the virtual disks have been created, we can proceed with the install:

Those who are familiar to HP SmartStart or Dell Server Administrator will see that Cisco’s utility is pretty much the same:

As shown in the following screenshot, you’ll get the following 4 options for the drivers you want to install:

From www.cisco.com

From SCU boot media

From Network Share

From USB stick on key

For the purpose of the example, I’m going to leave it at the default which is #2:

What I’ve noticed is that once the following screen takes a bit of time to process:

You’ll notice that the utility will auto select the RAID controller drivers for you and that’s because without loading these drivers, Windows won’t be able to detect the disk. Although you should try to select all the drivers you’ll need for the operating system (i.e. hba, NICs, etc), it’s ok to leave them out for now because you can always run this CD within Windows to install the missing drivers:

Once you click next, the drivers will get copied to the server and you’ll then be prompted for the Windows CD:

If you’re installing the operating system through the CIMC, unmap and remap the proper ISO and continue:

The utility will now copy the required files and then ask for a reboot to install the OS: