###Exchange Mailbox Statistics Script

###Modify Variable Data
$FromAddress = "noreply@domain.com"
$ToAddress = "administrator@domain.com"
$MessageSubject = "Exchange Mailbox Report"
$MessageBody = "Mailbox Statistics of Exchange Server is attached with this email."
$SendingServer = "exchangeserver.yourdomain.com"

####DO NOT EDIT BELOW THIS LINE

###Get Stats and Prepare Text File
Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | ft DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}}, ItemCount, StorageLimitStatus > mailboxes.txt

###Create Email and Attach Report
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress,
$MessageSubject, $MessageBody
$Attachment = New-Object Net.Mail.Attachment("mailboxes.txt")
$SMTPMessage.Attachments.Add($Attachment)

###Send Email
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer
$SMTPClient.Send($SMTPMessage)

Hope the above script helps and saves the administration time.

What does all this mean? Nothing but shelling out extra $$$ to invest in a backup solution unless you are interested in a very simple backup solution to assure that the logs get truncated and you have backup copies which you can restore. Here is a basic hack which can help one save a couple of $$$.

Step #1

Get access to a Windows 2003 R2 Server which is running a 64-bit OS. Assuming that you are not running your production Exchange Server 2007 in 32-bit environment, we require the 64-bit version library files. If you do not have a one handy, you can get the source files and then expand the DLL’s or install one in a virtual environment.

Step #2

Copy the ntbackup.exe, ntmsapi.dll, and vssapi.dll files from C:\windows\system32 into a new folder on your Exchange Server 2007 running on Windows 2008. I created a folder called NTBackup under Program Files and placed them there.

NT Backup Exchange 2007

Step # 3

Right click Ntbackup.exe and choose “Run as administrator”.

Your should see the Exchange Server Information Store as part of your backup wizard.

Select the Information Stores that you want to backup. Choose the Backup media or filename and the path where you want to store your backups. Once you have finished the configuration, click on Start Backup and the exchange store backups should start.

Once the backup is complete, you should see all the transaction logs getting truncated (hope circular logging is not enabled) and also the mail store would be stamped with the Last Full Backup date and time stamp.

One thing to note though: you cannot back up a storage group in a Standby Continuous Replication (SCR) environment. Backups of storage group copies are available for Local Continuous Replication (LCR) or Cluster Continuous Replication only.

The main idea is to make the URL more simple and SEO friendly. Normally, when you setup PermaLinks in IIS, we get something like this:

http://www.yourwordpresssite.com/index.php/2009/08/02/your-blog-post/

This means that each link to the post carries index.php in the URL which is not good. Outlined below are steps that can help to achieve the same results for a WordPress site on a Windows Server running IIS.

STEP: 1

Get the URL rewriting component on the Windows Server hosting your WordPress site. If you are not in control of the server or are not the server administrator, you can request the setup of the component from them. Click here to download the component from the vendor’s site. The component is absolutely free and distributed under GNU General Public License.

STEP: 2

Once the component is downloaded, copy the wp-url-rewriting.dll file to the Windows Server’s SYSTEM32 directory. Register the component so that it is available to IIS by using the REGSVR32 WP-URL-REWRITING.DLL command from the command prompt.

Note: You may get an error that the DLL entry point was not found, but let that not bother you.

STEP: 3

Once the DLL is registered, login to your WordPress admin area and navigate to PermaLinks and change the common setting to use Custom Structure. Add /%category%/%postname%/ as the choice and Save Changes.

That’s it! We are done. WordPress should now show the URL’s without the index.php in it.

I invite everyone to share their experience or any other methods that they might have used.

So why do we need a centralized patch management policy? Well, the answer is simple – the systems are prone to risks and threats when exposed to the Internet or medias like USB pen drives, wireless networks and devices, etc. We all, at some point, might have experienced or read about the havoc caused by Blaster or the Sasser worms. Today software vendors have stepped up the releases of emergency and critical updates in a formalized manner to encounter these threats. Microsoft’s Patch Tuesday is a good example that highlights that. To learn more about this program, click here.

WSUS from Microsoft is a boon to Network and System Administrators in this scenario. WSUS (Windows Server Update Services) is basically designed to run on a company’s network and automate the process of patching. This free product from Microsoft does a fair job of streamlining the overall patch management process of an organization with centralized reporting. For a Network or System Administrator it is just a simple task of installing the WSUS server on a system and then configures all Desktops to use the WSUS server for software updates. This can be easily achieved by creating a group policy and linking the policy to the correct OU using Group Policy Editor. The Desktops would automatically announce their current status to the WSUS server with details like which patches are needed to be installed, which patches have failed to install, which patches have been successfully installed, etc.

In a nutshell, WSUS seems to be a good product especially when there is no price tag attached to it and starting with WSUS 3.0 the reports have also improved over its predecessor.

Now that we have installed the Exchange Server 2007 SP1 in the organization, it’s time to move the user Mailboxes to Exchange 2007. Moving mailboxes is a very easy task and can be accomplished by using the Exchange Management Console or by using the PowerShell commands from command line. In this post I’m going to use the Exchange Management Console.

So, let’s open the Exchange Management Console and in the tree on the left, navigate to the Recipient Configuration and expand it. Under the node, select Mailbox.

Here we can see in the results pane that now we are able to see all the mailboxes that we have on our Exchange 2003 server and they are all marked as Legacy Mailboxes. This means that all the mailboxes are still on the Exchange 2003 Server and need to be moved to Exchange 2007.

In this example, we will move the Administrator mailbox. So we choose the account, right-click it and choose Move Mailbox.

The next screen provides us options as to where we want to move the mailbox and here we need to choose the mailbox database. I assume here that the Storage Groups and Mailbox Database are already created on Exchange Server 2007. If not, then that’s the first thing that you need to do.

In my example, I’m going to move the Administrator mailbox to the General Mailbox Database.

There now that we have selected the Mailbox Database, Exchange 2007 automatically appends it with the Server Name and the Storage Group. Click Next to proceed.

On the next screen we are presented with lot of options as what should be done if the Move Mailbox process encounters any errors or finds any corrupt messages in the mailbox. Either we can Skip the entire mailbox move or we can allow Exchange Server to move the mailbox and simply Skip the corrupted messages. Moreover, if we go ahead with that option, we can even define how many corrupted messages should be skipped before the Move Mailbox stops the process. Since, I would not like to skip any messages, I’ll choose “Skip the Mailbox” and move further.

Next we are presented with the scheduling screen which allows us to schedule the Move Mailbox process. This helps in particular when you are in a production environment with heavy traffic and want to schedule this unattended during off-peak hours. Moving mailboxes does not take much time and is entirely dependent on the number of items in the mailbox. Even in a production environment, while moving mailboxes, the user will hardly notice any issues and after moving the mailbox, the user may simply need to restart Outlook to get everything working again.

In the scheduling option, you can choose to move the mailboxes during off peak hours and also you have a choice to cancel the running task if the move mailbox task runs for certain hours. I’ll chose “Immediately” and move ahead in this example.

That’s the last screen that we see before we actually tell exchange to move the mail box. It allows you to do a quick round up of what we have selected and what options have been set. Once we have reviewed the options, click on “Move”.

While the mailbox is being moved, we can see the progress, the number of items found, the number of items moved, etc. If you select multiple mailboxes, note that by default Exchange 2007 moves only 4 mailboxes at a time. The remaining mailboxes will be shown as “Pending”.  Lot of checks are performed in the background by the Exchange Server during this process.

If all goes well, the final screen that we see is the confirmation showing us the status of the Move Mailbox process. Click on “Finish” to close the wizard. That’s it to Moving Mailboxes from Exchange 2003 to Exchange 2007.