Microsoft officially released a public Beta of Exchange 2010 which was formerly code named ‘Exchange 14”. I was already blinded by the features that Exchange 2009 provided – Unified Messaging being the best of the many and now we have Exchange 2010 in the pipeline. There are so many improvements in this version that I can’t decide which ones to highlight and talk about first. The product claims to achieve high levels of reliability with greater flexibility, enhanced user experiences and increased protection for business communications.

OWA (Outlook Web Access) has been scaled out to support Internet Explorer – 7 and 8, Firefox 3 and Safari 3. Users will no longer be restricted to using Internet Explorer. OWA has been further improved to provide a web user with all the functionality of Outlook desktop client. Also, a new feature of conversation view has been added greatly reducing mailbox clutter.

Voice Mail Preview is another feature that deserves applause. OWA and Outlook 2010 support voice mail previews. Exchange 2010 automatically generates text based preview of a voice mail message received. Not sure how accurate this is going to be but the concept itself is worth it.

Users will be able to create and moderate their own Distribution Groups and can also decide who they want their Calendar and Contacts shared with.

Ever got bounce backs after sending emails with large attachments or accidently sent a personal email to everyone in your company? Now you need not worry about that. MailTips is a new feature added up which prompts you before you send a message.

Message Tracking and Delivery Reports has been improvised in Exchange 2010 – works well inside the Exchange Organization and federated servers.

No more Administrator privileges required to scan or search other mailboxes in the organization to meet compliance. Authorized users can perform MultiMailbox Searches without the use of administrative rights.

Self service via Exchange Control Panel (ECP) is now made available to the end-user. This means that a user can now update their personal details in their account which earlier required a help desk call or ticket.

Database portability and multiple options for high availability were already made available in Exchange 2009. These have been further improved in Exchange 2010 and also open possibilities of reducing the operations costs. Database Availability Groups now gives redundant mail stores with continuous replication. Database-level Failover gives automatic recovery and the I/O optimizations make Exchange 2010 better suited for SATA drives.

These are just some of the powerful features that have been released in the Beta. We may be having a few more added to these in the final specimen. Overall the new version of Exchange looks very promising and exciting.

Since I maintain and administer lot of Windows and Exchange Servers, running basic disk checks and defrag on the servers manually is simply impossible. To achieve the goal, I had a small batch file written which automates this task for me.

To start with, create a folder on the machine that you want to automate this on. I named my folder as “MaintenanceScripts”. The next step was to write the batch file with the content given below and save it as “ChecknDefrag.bat”.

@Echo Off
REM ***************************************************************************
REM *                                                                         *
REM *      AUTOMATED DISK CHECK AND DEFRAGMENTATION SCRIPT                    *
REM *                                                                         *
REM ***************************************************************************

REM chkdsk and defrag automation
REM Read the Drive Letter from the file
for /F "eol= tokens=1 delims=( " %%i in (DriveLetter.txt) do set DrvLtr=%%i& call :dsKchk

:dsKchk
If %DrvLtr% == end goto :eof
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo CHECK DATE and TIME for %DrvLtr% >> diskcheck.rtf
date /t >> diskcheck.rtf
time /t >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo RUNNING DISK CHECK ON %DrvLtr% ....
chkdsk %DrvLtr% >> diskcheck.rtf
goto :defrag

:defrag
echo. >> defrag.rtf
echo. >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo CHECK DATE and TIME for %DrvLtr% >> defrag.rtf
date /t >> defrag.rtf
time /t >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo. >> defrag.rtf
echo. >> defrag.rtf
echo RUNNING DISK DEFRAGMENTATION ON %DrvLtr% ....
defrag %DrvLtr% -b >> defrag.rtf
defrag %DrvLtr% -f >> defrag.rtf

:EOF

The above batch file checks for a file called “DriveLetter.txt” in the same folder from where the script it going to run from. You can change it to your liking. It also saves the report of the disk check to a file called “diskcheck.rtf” and for defrag to a file called “defrag.rtf”. I choose RTF so that I can open it in MS Word or any other application to see a nice formatted output.

Next, we create a file called “DriveLetter.txt” in the same folder where we saved the Batch File and add all the drive letters that we want the script to check:

C:
end

You can add more disks to the above file by writing the drive letters to the text file – one drive per line.

Run the batch file once and wait for it to finish. Once it finishes its run, you can open the RTF files and see the results. If you are satisfied that everything is working fine with the batch files, you can now move towards scheduling the batch file to run at off-peak hours.

Companies that have implemented Microsoft’s Active Directory need to ensure that the Active Directory is configured and operating properly. If there are issues found and not resolved, it eventually leads the components to fail or stop working and finally causing problems with Windows networking environment. This post highlights some of the FREE tools that can be used by administrators to check and verify their Active Directory health. I normally run these tests every quarter in highly changing environments since lot of updates take place.

The free tools that I mention come with Microsoft’s Support Tool Kit and while writing this post I’ve ran the tools on Windows 2003 R2 Server. Download the Support Tool Kit. Once downloaded, install the Support Tools on the server.

Now before we move on to the health monitoring tools, it is always a good idea to make a list of all the Domain Controllers in your organization along with their IP address and trust relationships if any. Assuming that you have completed this step, let’s move on to using the tools.

Since many of these tests generate logs, let’s start by creating a log folder to store the diagnostic information. I’m going to use C:\AD-Health-Logs on my server.

Let’s start by verifying the health of the Domain. For this we are going to use NSLOOKUP which is a command line tool for testing and troubleshooting DNS. We all know that DNS is the heart of Active Directory and so that’s the first thing that we will check.

For replication to happen seamlessly between multiple Domain Controllers, name resolution should work fine. Each DC should be able to resolve the _msdcs record for other DC. Open the DNS mmc and look for the _msdcs record.

Once you have the _msdcs record for the DC object, we can use NSLOOKUP to check the name resolution. Open Command Prompt and type:

NSLOOKUP <GUID._msdcs.DnsForestName> replace the GUID string in <> brackets with your actual GUID.

If the NSLOOKUP resolves the correct IP address of the replication partner than DNS is working fine. Do check that the DNS server returned in the NSLOOKUP query is returning the correct records for the replication partner.

Since DNS is working fine now, let’s move on to checking the Replication functions and topology. To verify this, we are going to use REPLMON. This tool is included in the Windows Support Tools kit and offers a GUI based interface to check a low-level status of AD replication, force replication or even monitor the status of replication. You should find REPLMON utility from the Support Tools group under Administrative Tools.

Once the GUI is opened, right-click on the Monitored Servers and click on Add Monitored Server.

This will invoke the Add Monitored Server wizard. Here either you can search the AD for the server that you want to monitor or you can add it explicitly by name. Since I’ve already documented my list of Domain Controllers and their corresponding IP address before I started this exercise, I’ll add the server explicitly by name. Once the server is added, click on Action, navigate to Server and choose Generate Status Report.

When prompted for the location where we should store the log file, choose the folder that you created earlier. In my case, I’m saving this to C:\AD-Health-Logs. Choose all the reporting options on the next screen and click OK.  Once the report has been written to the Log file, you’ll see a message that the Report is complete. You can now navigate to the folder where you saved the log and open it in Notepad, Word, etc. to read the contents. The report basically gives you lot of in-depth in to the replication status and topology. Play with the other options available in the REPLMON tool like Show Domain Controllers in Domain, Show Global Catalog Servers in Enterprise, etc.

My REPLMON log files did not show any problems with replication and so we will now move forward to perform the DC health check. Open Command Prompt once again and type the following command:

DCDIAG /s: <ServerName> /v /c > C:\AD-Health_logs\<servername-DCDIAG-DD-MM-YY.log>

Replace ServerName with the actual DC name and the log path with the actual values. Using the /v switch will provide us a verbose result with extended information while the /c switch will provide us with a comprehensive report by running all tests. If you get any errors you can also use the DCDIAG /fix option here to perform some soft fixes. Run this for all the DC’s in your organization by replacing the ServerName and the log file prefix. You can run this from the same machine and does not require you to log individually to machines that you are checking.

Moving ahead, we will check the network connectivity health using the NETDIAG tool. The NETDIAG tool helps in isolating network connectivity problems by performing a series of tests. Open the Command Prompt once again and type NETDIAG /v > C:\AD-Health_logs\<servername-NETDIAG-DD-MM-YY.log>.

Again replace the appropriate variables with the actual values and wait for the diagnostics to complete. Open the log file once the process has completed and remediate any errors that you get. Note that you may see errors related to WINS in this. If you are not using WINS in your organization these can be safely ignored.

That’s it to the basic checks for monitoring the health of your Active Directory. I’ve not covered NetDom in this series since most of the functionality can be accessed from the Active Directory mmc’s that are available in the Administrative Tools.

Finally I decided to move away from Blogger and setup my own blog using Wordpress.  This does not mean that blogger is not good, but I wanted some extra flare on my blog which only Wordpress could provide. The main thing behind the decision was the way Wordpress offered ‘categories’, plugins and widgets.

The import from Blogger to Wordpress is like a cherry on the cake. I could easily import all my old blog posts from blogger to the new blog in Wordpress with a press of a button with the only exception that it broke all my links to the images. This happens because Wordpress stores images in a different manner than Blogger.

Another feature that floored me was Permalinks. Wordpress allows me to save my pages with static links. This really helps with the SEO part.

The plug-in called AKISMET also helped in protecting the comments on my posts from SPAM. This used to be a problem with Blogger.

Final word: my 2 cents to wordpress blogging.