Serivce Pack 2 for Exchange Server 2003 introduced some new configurable settings for information store database limits. These limits used to be hard coded depending on the version of Exchange you were using. Standard Edition was capped at 16GB and Enterprise Edition was capped at 8TB (which is the largest an Exchange Jet database can be). After applying SP2, administrators can now set arbitrary limits to the sizes of their information stores. Standard Edition users are still limited to one private and one public store, but can set both of them to a maximum size of 75GB! It is not configured this way out of the box, however!
By default, post-SP2 Standard Edition servers have their information stores set to a maximum size of 18GB with a 10arning threshold. This warning percentage replaces the "dies at 16GB, then set a registry tweak to give you 1GB more temporarily" way of dealing with the database cap previously. The new way warns administrators via the event log 24 hours in advance that the warning threshold has been reached. If no action is taken in that time period, the information store gracefully shuts down. When everybody at your company cries that their email doesn't work, you can turn it back on for another 24 hours and clean up the space in the mean time. However, if your store reaches it's hard limit, you are back to the old "registry tweak to get one more GB" scenario. But at least you have new options and more time now.
If you have the hard drive space to increase your information store from 18GB to 75GB (or anything inbetween) you have to set a few registry values to make these changes.
I was bored, so I made a tool to do this for you. Keep in mind that it tinkers with Information Store registry keys, so use it with caution and test it first, as you should any new piece of software before deploying it to production servers!!
Exchange 2003 Enterprise Edition users might find this useful too, should they want to cap their databases to fit within the constraints of their hard drive and create warning thresholds to keep it from potentially corrupting the database by reaching that limit of the hard drive. Graceful shutdowns are your friend! By default, Enterprise Edition has no limit set (other than the 8TB hard limit which is constrained by the fact that Exchange just can't handle a single information store larger than that).
Let me know if you use this tool!
Here is the link...
I manage a domain of about 70 Windows machines. About 30 are 2003 servers. The rest are XP workstations. Initially I disabled all the local built-in admins for security purposes using Group Policy, but then I ran into a trouble PC that couldn't communicate with the domain. Uh oh. What do I do now? Turns out the network card was bad, so when it was replaced, everything was fine. But since I had never logged onto that machine with a domain admin account before, there was no way for it to authenticate that I was a domain admin (no cached credentials for the domain admin account). The local admin was still disabled and there was basically no way to administer that machine. What if this happened and it wasn't the NIC? Heck if I'm going to reinstall Windows for an oversight like that!
So I re-enabled all the local admins using GPO again. I had every admin I ran into changed to the same password for a little while. But this is insecure too because what if that password is compromised? I'd have to walk around to every computer, or at least connect to every computer via Computer Management MMC, to reset the passwords. Ugh! Not fun.
So I looked around for a tool to automate this. The only solutions I could find involved writing startup scripts and implementing it through a GPO. This is bad for several reasons. (1) The new password is stored in plain text and transmitted in plain text over the network (or, at best, obfiscated somewhat, but not truly encrypted). (2) Startup scripts cannot be guaranteed to run. If the machine connects with a wireless card, the pre-logon state where startup scripts run may not have an active connection in time for it to run. This means that the script never executes, but the event log kindly tells you it didn't execute. Also, some people never reboot their machines. That's fine normally, but if you rely on a startup script and a mandatory reboot from Windows Update, this isn't a good solution.
So I created XS BAP. XS because that's the name of the company I work for and they signed my paycheck while I designed this happy tool. BAP is for Bulk Admin Password tool. This tool is currently freeware and is provided with no warranty. This tool is not open source, so don't ask for the source code. The licensing agreement on subsequent versions of this tool may change without notice.
XS BAP allows you to import or manually enter each computer you want to manage on your domain. You can then specify the administrative password you want to use, or use the random password feature and get a unique random complex password for every machine. You can then update all machines at once, or only selected machines. After updating the password, you can verify that the password works using the verification feature.
XS BAP requires the .Net Framework 1.1. XS BAP works by resetting the Administrator password to whatever you specify, so you do not need to know the old password of the adminsitrator ("reset password" method, as opposed to "change password" method). However, you do need to have local administrative access on every target machine. In a default Windows domain, Domain Admins have the appropriate level of access, so run this tool as a domain admin. I do not know how well this application scales, but I have used it on every machine in my domain at once. If you use it on a very large domain (hundreds or thousands of computers), let me know how it works! It will probably be slow, but hey... Slow and unattended is better than nothing!
You can save the data in an AES encrypted file (encrypted by supplying a password). This way when you need the password of that workstation you've never looked at before, just open the file and there it is! For additional security, I highly recommend also implementing EFS (NTFS's Encryption) on the saved password files. After all, compromise of the saved file will give an attacker the local passwords of every machine! Since the password file is symmetrically encrypted with a password, a brute force attack could theoretically, eventually, lead to a decrypted file. The encryption will certainly buy you time to change the passwords, should you ever discover that the password file was obtained by unauthorized personnel. But it is not hack-proof!
The interface "feels" like Microsoft Access since it uses the DataGrid control interface. The help file sucks, but well.. I'm a developer, not a tech writer. Maybe I'll add to it later! Hopefully it will be somewhat self-explanatory. If you have a question, post it to the blog here.
Known limitations: (1) If you import multiple domain controllers and modify the same account on each of them with a different password, the LAST password that was successfully "updated" is the current password. There is no feature to let you know if you are updating a local workstation/server SAM database or Active Directory through a domain controller. As a general rule, don't update domain controllers to save yourself hassle. (2) The verification process attempts to change the password to the same value to make sure the password works. This seems like a weird way to do it, but all the other logon methods I could find did not allow you authenticate to a remote machine's SAM in .Net. If somebody knows of a better way, let me know. Anyway, since local administrators are exempt from certain password policies (such as minimum age), this method should always work. However, I make no guarantees that the verification process will not say "Failed" but then work when you try it manually on the target machine. On the flip-side, though, if it says "Correct" it definitely works.
If you have any questions, comments, or suggestions, reply to this post!
Here is the link to the file:
At the time of this posting, there is only one version (1.0), and I will post to here when newer versions are released. I will probably keep a little bit of a history on the download server, but may not keep all the versions online. Haven't decided yet.
Let me know if you find this tool useful!
I'm mainly starting this blog to have a place to post Windows administrative tips I discover, post tools I've written, and to discuss with other Windows administrators administrativey things! I will also post other techy topics and hopefully people will visit, despite the gazillion other blogs out there... If somebody out there in the great vast ethos of the internet finds some of this stuff useful, I will be happy.
Update: This blog was moved from MySpace to my personal website on April 22, 2006. (Just FYI)