Today I’m going to talk about the wonderful thing that is the Resource Manger for HMC (Hosted Messaging and Collaboration), the wondering framework from Microsoft for provisioning users for Exchange, OCS and SharePoint automagically.
Now, we tend to do things a bit differently at my current job. For example, I’m pretty sure I’m the only developer in the US that is hitting HMC (again, a Microsoft product) with PHP hosted on our linux based customer portal. That’s right, the Unix guys is the lead developer hitting a very Microsoft-centric product. Normally this would be done by a .Net developer.
So what does the Resource Manager give you? Well, the resource manager allows you to add, edit, remove mail databases for use on the system in the Exchange world which is what we are mainly going to focus on. When you first setup these resources, you set certain parameters for the mail stores. Do you want the domains on there to be tightPack or minStoreCount. TightPack attempts to use the smallest number of mail stores. MinStoreCount attempts to minimize the number of stores allocated to each org. We have gone with the minStoreCount model as we want to have all the users of the same domain live on the same store if possible.
Which is good in theory, but Microsoft has an extremely poor implementation of this.
Here’s an example. There is a domain on our system. The users used to live in 2 mail stores. We moved the users, through HMC calls, to all live in the same mail store. Now, when we create a new user, we do not specify the mail store. We rely on HMC and the resource manager to put the user in the correct location. Unfortunately, Microsoft drops the ball big time here. Instead of putting the user on the correct mail store with the other 30 accounts, it instead picks the old store that has no users on it. It fails to figure out that the mail store has been abandoned by that domain and continues to put users there.
Nice right?
So how do we get around this? Simple, write our own and tell them exactly where to put it. Yes, that’s right, recreating the wheel. Well all know we don’t need a rounder wheel. But in this case, we’re actually improving the functionality of the system.
I can’t go into the detail of how we actually implemented our system. But I can tell you, its already paying off by putting the users in the correct location.
But but but…is that it? Is that all you really solved? Do you really care if the users are spread out? Well, yeah, we do. We want them to be in the same mail store to help save on space for those messages that have the same attachment that went out to every users in the organization. Its not going to save you a ton of space, but it does save a lot more than you think it does.
But the placing of users isn’t the only improvement that we got from writing our own resource manager. One lacking feature of the resource manager is the ability to mark mailstores as non provisionable. I’m sure I’m going to get someone from Microsoft telling me that yes you can, there is a bit you can flip. And I’m here to tell you, they’re right, but they completely missed the boat on actual implementation.
It is true, you can mark a mail database as non provisionable. However, when you create a new user, HMC will ask which databases the domain lives on and picks one of them. note, it doesn’t query for all the databases that are provisionable, it asks for ALL of them for the domain. There is a chance, a very GOOD chance that HMC may automatically pick one of the stores that you have marked as not provisoinable. Awesome I know.
So how do you get around this little gem. Well, you can mess with the resource manager as we ran for a while. We had a script that would run daily and check a list of databases that we had marked to not have new users on them. Then it would check out the free space on the system and mess with the resource manager basically tricking the resource manager that it would be out of space. This had the same effect of not having new users allocated to it on the system as the resource manager would at least check to see if there was enough space on the database when putting a user on there. But even this had its drawbacks. For example, what if you have a system setup where you have plans in place where a user can have a 1GB, 2GB and 4GB mailbox. They have the 1GB plan and want to upgrade. Guess what, if the datastore doesn’t think that there is any more space on the drive, you you CANNOT upgrade them. Why in the world would you ever want someone to upgrade their account and spend more money with you. Crazy talk I know.
I’m sure you’re thinking, how in the heck did you ever come up with these crazy ways of mail database retirement. These suggestions came from Microsoft themselves. Even our premier tech support guy (who is awesome btw) didn’t know that these changes would cause such ass ache. Its like they never ran into a situation where someone would want to mark a database to not have any more new users allocated to it.
Our solution, write our own resource manager. not for the weak of heart, but I’m also not a pansy when it comes to this sort of thing. What we have done is put in place a system that keeps track of where each user, domain and mail store is located, how many users per store and where each domain lives. We can easily query this for the best place to put a user, but also the best place to put a user even if you have retired all the stores that the domain lives on, the system is smart enough to place the user on a new datastore for that particular domain. now when a new user is created, our provisioning system queries the resource manager, gets the appropriate store and we put that once “optional” parameter in HMC in the request XML and basically bypass the pile of shit resource manager that Microsoft has given us.
I’m sure that the big boys out there in this space will laugh at this post. I’m sure that they are way past where we are at. Or they have a bigger team that ran into this problem and put in their own solution. But if you happen to be starting out and are relying on the HMC resource manager, you might want to think again on that one. Eventually, you’ll write your own.
