Upgrade domain to Server 2016
Upgrade VMware to 6.5
Upgrade to Exchange 2016 with SSL
Upgrade/Add Router for CL Geo Maz
Upgrade Firewall firmware
Install Century Link Geo Max to Salt Lake City
Add VPN for Herriman City Police
Add EEOC to website for Human Resources
NetApp install and configuration.
Create and install new 2012 domain
Migrate data from HP Lefthand Network storage to NetApp and new domain
Create users and shares on new storage. Create better security checkpoints
Forklift install of Avaya Phone switch including Audix.
VECC documentation Wiki/Knowledge base portal redo.
Cad2Cad connection to Utah Highway Patrol. Configure microwave network and add associated connections.
Over the past couple of days we have been installing a NetAPP SAN storage solution. Its up and configured and ready for data. I am beginning to move data from our HP LeftHandnetwork storage. Our Microsoft Exchange database has filled its LUN on the HP and needs moving pronto.
While trying to run the Move Database Path from inside Exchange Management Console I ran into an error at about 9 minutes into the move.
Failed to connect to target server "ExchangeServer". Error: WMI exception
occured on server 'ExchangeServer.domain.local': Quota violation
I tried it again wondering if it was just a fluke. I tried it in powershell. No luck same error.
This install of Exchange and its database is not quite a year old and we had a size of 250 GB database. After searching through Microsoft;s Technet and Googling like a wild man, I came across others who had experienced the same problem. It turns out that this error is a feature of having to many transaction logs. Sure enough we had too many transaction logs.
There are three methods you can use to have Exchange clean up your unruly transaction logs.
1. You can copy everything manually and re-point. This seemed to be too much work and the internet reaction on success was mixed at best. Not a good solution in my opinion.
2. Do a backup using Microsoft Server Back Up Utility. It’s easy and straight forward but a tad time consuming.
3. Enable circular logging and remount the database. This was the option I took and it was quick and easy. It took less than 3 minutes and was successful. You must dismount and mount the database.
How to Enable Circular Logging Through Exchange Management Console (EMC)
- Under Organization Configuration click on Mailbox;
- Click on Database Management where you find Databases;
- Take properties by right click and under meiantenance tab apply check of Enable circular logging.
By Using PowerShell
Be sure to remember to re-disable it when done.
The Information Store must be restarted for either of these changes to take place!
Today one of my Outlook power users received an error while trying to add a spam rule filter. The error was…
“One or more rules could not be uploaded to Exchange server and have been deactivated. This could be because some of the parameters are not supported or there is insufficient space to store all of your rules.”
It turns out that Exchange has a rule for the size of mailbox rules.
The rules size limit for mailboxes in Exchange Server 2007 (and later) has a default size of 64 KB per mailbox. The total rules size limit is also customizable limit up to 256 KB per mailbox.
More Information: http://support.microsoft.com/kb/886616/en-us
Exchange 2010 rulesquota size limit and how to increase it.
By default Exchange 2007 / 2010 rule size is 64 KB but is expandable to 256 KB.
How to Check the Size:
Get-Mailbox email@example.com | fl rulesquota
RulesQuota : 64 KB (65,536 bytes)
It was 64KB. Increase it’s size to 256KB:
Set-Mailbox firstname.lastname@example.org -rulesquota 256KB
Recheck New Size:
Get-Mailbox email@example.com | fl rulesquota
RulesQuota : 256 KB (262,144 bytes)
It Can Be Set for All Users as well:
get-mailbox|set-mailbox -rulesquota 256kb
Recheck Your Work
get-mailbox|ft rulesquota, alias
Recently I had a user whose Out of Office Reply was stuck on. I hadn’t encountered this and a simple Google search and the fix was allegedly as simple as choosing start, run, Outlook .exe /cleanrules. This didn’t work so I did option 2 which was logging in to Online Web Access (A silly name that seems redundant) and turning off the auto responder. It was fixed in a snap… until it resurfaced a day later.
Another odd feature of this bug was the fact that you couldn’t turn on/off the auto responder nor edit the auto responder via Outlook.
We are a Microsoft Exchange 2010 shop with users that use Outlook 2007 or for the majority OWA. Don’t Judge! It’s just part of the joys of being a grossly underfunded IT department. It appears via more Googling that this is a common problem amongst users of Exchange 2010 and Outlook. There were a lot of web pages advertising they could fix my problem but the solutions were varied and many I didn’t feel comfortable using.
I pondered… Could I fix this using Powershell?
I bet I can. In simple terms, Microsofts Powershell is a powerful command line utility that allows a system administrator to use simple commands, script command etc and give full access to local and remote computers including COM and WMI features. Microsoft’s TechNet website has complete documentation of available commands.
The first command I ran was Get-MailboxAutoreplyConfiguration username
It shows the mailbox out of office responder, state enabled or disabled.
The next command I ran was Set-MailboxAutoreplyConfiguration username –AutoReplyState DISABLED
This command disables the auto responder.
I logged into Outlook and now I could edit and change the auto responder.
Fun Fact of the Day:
Why is “out-of-office” abbreviated “OOF” in Microsoft documentation?
Because originally it was called Out of Facility.