As an Exchange administrator, it’s helpful to have a relatively effortless way to determine if a user’s mailbox is approaching its limit in terms of disk storage space. We achieve this by using the Get-MailboxStatistics commandlet and look at the value returned in the StorageLimitStatus property. Think of StorageLimitStatus as a fuel gauge for mailbox disk space utilization and is relative to the quotas being applied, whether at the database or mailbox level.

If you’re unlucky lucky enough to still be supporting Public Folders, you probably don’t(care) to know that there is a similar statistics generating commandlet for public folders: Get-PublicFolderStatistics. Alright, now that you know that - time to go home for the day. Wait..what? At first glance, it looks pretty similar. It spits out some unique identifiers, TotalDeletedItemSize, TotalItemSize, etc. What’s missing? StorageLimitStatus.

What is similar about mailboxes and public folders are that they generate a storage status message during your nightly database maintenance schedule that is delivered to the mailbox/PF. That’s great for your individual user mailbox, but not for your 27 person HR department that utilizes that public folder. Guess what? Bob from HR gets to work about 30 minutes before everyone else and takes pride in being the first employee to read(or not) and delete the warning message. What Bob didn’t tell anyone was that the HR Public Folder is 1MB from being full. When you go to add a message to it later that afternoon, Outlook gets you with a cryptic error dialog that has nothing to do with storage space or quotas (Something along the line of Cannot move items). It’s 4:02PM, so naturally Bob has left for the day. This issue escalates its way through your IT organization and eventually to your Exchange administrator (you). Instead of spending a bunch of time fumbling through the Exchange Management Console remembering where in the hell the Public Folder Management Console is hidden, I suggest using the Exchange Management Shell. Below is a PowerShell that script uses Get-PublicFolderStatistics but in addition, goes through the trouble of determining the Public Folder database limits as well as the overridden limits (if any) on the folder and then determines a storage limit status based upon the folder’s TotalItemSize property. The syntax is:

GetPublicFolderStatistics_v2.ps1 -folderpath “\WhateverPF” | select FolderPath, StorageLimitStatus

Recently, I had to enable ACS Forwarding on a percentage of the systems reporting to my SCOM Management Group. All of the examples that I found on the Internet were for enabling ALL of the systems in a management group. For me, that was about 5,500 systems too many. So, I made a quick PowerShell script that did the job for me. There are 2 parts to this script. 1.) Input File - This file containts the list of hostnames that you wish to enable ACS Forwarding on. 2.) PowerShell Script. Here is an example of the script:

ACS_Enable.ps1

#### FUNCTION DECLARATION BEGIN

Function enableACSForwarder
{

param ($targetHostname)

Write-Host “Enabling Audit Collection for:” $targetHostname
cd <mgmtserver>\Microsoft.SystemCenter.AllComputersGroup\$targetHostname\Microsoft.SystemCenter.HealthService
Start-Task -task:$enableAcsTask -overrides:$overrides -credential:$credentials

}

#### FUNCTION DECLARATION END

$collectorServerName = “<your collector server name here>”

$enableAcsTask = get-task -path \ | where {$_.Name -eq ‘Microsoft.SystemCenter.EnableAuditCollectionService’}
$overrides = new-object Hashtable
$overrides.Add(“CollectorServer”,$collectorServerName)
$credentials = Get-Credential

get-content C:\acs_enable_input.txt | ForEach-Object { enableACSForwarder $_ }

Ever find yourself sifting through specific event logs after debugging a script or application? Do you do the old “hurry up and switch to Event Viewer so I can catch new events” technique? With wevtutil, put this command in front of your script and enjoy event logs that are relevant from the time of execution forward:

wevtutil cl log_name /bu:backup_location_before_clear

wevtutil cl Security /bu:C:\security_backup.evt

I recently ran into a problem where a single Guest virtual machine on a VMWare ESX host was consuming too much bandwidth (70megabits/second!). When I configure a basic ESX host, I usually am working with a server that has two Ethernet Interfaces. I end up using one interface for management and the other as a virtual switch in which one VM Port Group is created that all the guests utilize. Luckily, VMWare has some cool policies that can be applied to Virtual Machine Port Groups. One of these policies: Traffic Shaping. Now, you could very well apply this policy to your standard VM Port Group, but that means all of the guests on that port group would then be impacted by this policy. In my case, I only want to apply Traffic Shaping to one virtual machine. Note that the same steps can be adapted for a single port group.

In vShpere, select the ESX host that you wish to configure. Select the Configuration tab on the top and Networking from the hardware selection on the left hand side. When in the Networking pane, make sure Virtual Switch is selected.

In this view, select Add Networking on the right hand side of the screen.

Choose Virtual Machine

Select the virtual switch that you use for your guest VMs

Give it a cool name. Something like “Shapped_Traffic” (an obvious typo).

Here is a preview of what is about to happen: You are adding an additional VM Port Group to your existing virtual switch/physical adapter.

Cool. So now that we have this VM Port Group created, we need to edit the Traffic Shaping policy for it. Select Properties on the virtual switch that your new Port Group resides on.

Choose your newly created port group and Edit it.

Choose the Traffic Shaping tab, enable the policy, and set your desired bandwidth settings. *NOTE that Average and Peak bandwidth are measured in Kbits/sec VERSUS Kbytes for your Burst size.

When your policy is created and ready to rock, edit the Network Adapter settings on the virtual machine in question and choose your newly created VM Port Group as its Network Connection.

Enjoy your total control!

DFSR is an extremely important piece of my daily environment. I primarily use it as it was intended - to efficiently replicate files from one location to another over a slow to average link. But, my situation is slightly unique in the fact that files always originate on the far end of the link (remote site) and replicate to a datacenter. Once DFSR replicates this data to the datacenter, a “data monster” moves the data from the near end DFSR server into some giant information warehouse in the sky. So, let me recap this process from start to finish and with a little more detail. 1.) Data is generated on the far end. 2.) DFSR replicates this data to our datacenter DFSR servers. 3.) The “data monster” moves the data from the datacenter DFSR server to it’s final resting place. 4.) The datacenter DFSR server tells its far end replication partner, “Hey there, this file is gone, so please tombstone (delete) this file on your end. 5.) The far end DFSR server deletes the data as instructed and life goes on. Let’s call this the “transfer lifecycle.”

Once this data is generated at the far end and moves to it’s final resting place in some data warehouse, we no longer have a need for it to exist on the far end DFSR replication partner. That’s why it’s not a big deal that when that data is moved off of the near end DFSR partner, it’s also removed from the far end replication partner.

Initially, my team developed this relatively efficient PowerShell script in which its only job was moving data from the near end DFSR partner to the data warehouse. This script never really gave us much grief. I must admit that it seemed a bit sluggish at times, but it wasn’t so insanely fast that we would go around giving high fives about it either. Up until this point, both the script and the DFSR process itself was running smooth and we didn’t experience any bottlenecks. One day my team decided to write an application that would run as a service on the near end DFSR replication partner, replacing the PowerShell script.

When this application was implemented, we stared to notice two things. 1.) We were randomly receiving TONS of duplicate files and 2.) it would take 5 times as long for a large group of files to fully complete it’s “transfer lifecycle”. Again, this only happened for a large group of files being transferred.

After lots of trial and error, here is what I discovered. Our near end file moving application was too efficient! Before DFSR could complete the entire transaction of a large group of files, our application would have already moved it off of the server! DFSR would then say, “Hey! The file was here and now it’s not - let me try again.” This explained the large number of duplicate files. Even though it would retransmit over and over again, DFSR was intelligent enough to slowly catch up. This explained the increase in time to complete the “transfer lifecycle.” I attribute these results to the increased efficiency of using the Windows API for file movement and WAN link performance (or lack there of).

In the end, we determined that increased gaps of time in which the process would look for new file arrivals would take care of this issue. Lesson learned. Don’t try to beat something at it’s own game unless you are fully informed and fully prepared!

Sorry that I’ve been distant. Been on a long smoke break in the Datacenter.

MMS 2009 Begins..

XenServer Vitals

Campus Wide Nortel to Cisco Swap

dalas verdugo - “buying some of IT”

So awesome.