In BPOS, Microsoft, Technology, Varrow on February 21, 2012 at 12:57 pm
For those of us who are “blessed” to run our e-mail environments on Microsoft’s hosted Exchange service (curently BPOS – Business Productivity Online Suite, soon to be Office365), some not-so-recent news has come to my attention concerning users with a high item count in their “critical path” folders. Microsoft published a document entitiled FAQ for Message Record Management in October 2010 detailing how they will be handling these types of users in the future.
The following is a table outlining Critical Path folders and the upper thresholds under which they will operate optimally:
- Inbox: 20,000 items
- Sent items: 20,000 items
- Deleted items: 20,000 items
- Calendar: 5,000 items
- Contacts: 5,000 items
Microsoft will migrate e-mails that bleed over these thresholds into a new set of folders that will be automatically created within the user’s mailbox. This process is known as Message Record Management (MRM) and the results will look something like this:
Note that this process is only engaged for users with high item count and has nothing to do with mailbox file size. Click here to visit Microsoft’s technet for more details on MRM.
All content and images taken from Microsoft Exchange Online Standard: FAQ for Message Record Management, published October 2010.
In Cisco, ESXi 5, Technology, UCS C-Series, Varrow, VMware on February 15, 2012 at 11:12 am
I recently finished working a case for a new customer with VMware support and Cisco TAC. One of their hosts became totally unresponsive (VMs were still up, but host was disconnected in vCenter and you could not even console directly into the host). This also happened to a second host about a week prior. Both required reboots to fix the issue.
According to Cisco TAC, this is a known bug with ESXi 5 and UCS C-series. Cisco’s short-term suggestion was to disable Interrupt Remapping either via ESX or the BIOS – they claim that they had one running in a lab in this configuration that had been 3 weeks without an issue. Supposedly, Cisco is releasing a BIOS upgrade that will correct this issue “within the next couple of weeks.” Unfortunately, it has already been several weeks since this incident with no BIOS update but I will update this post as soon as I hear otherwise.
On a mostly unrelated but similarly important note, Cisco also confirmed that Call Manager is not yet supported with ESX 5.
Interrupt Remapping directions from VMware:
Link for latest UCS Update Manager (for when the new BIOS is released):