Microsoft released Exchange 2010 Service Pack one today. You can download it here. There many things that come with SP1 that I have been waiting for. I have been keeping tabs on the progress and reading about the new features, here are some of the Exchange Team Blog articles relating to SP1 that I found valuable:
I’ve been meaning to blog for a while now and have finally decided to take the time and set something up. I’ve decided to use WordPress (http://wordpress.org) and host the site on my long time hosting provider, Omnis (http://omnis.com).
The setup was fairly straight forward. My hosting provider actually had WordPress listed as an installable package. After a few clicks I was in business, thank you Omnis.
I spent about an hour poking around the admin control panel, setting various settings. I also wanted to be able to upload content from a client, rather than being required to post from a browser. I thought that would come in handy when trying to document thoughts even if I wasn’t “plugged in”.
I was pleased to discover that Microsoft Word 2007 was a supported client has some built in publishing features, and they support the use of publishing to WordPress using XML-RPC. Here are the sites I used for reference.
I am using the Word 2010 Beta, so I decided to give that a try. There is a Share option on the File menu that included Publish as Blog Post, the wizard walked me through the setup. I did get an error my first try, because I did not enable XML-RPC via the WordPress control panel. I found that disabled by default. Once I enabled that the wizard completed successfully. Everything is looking good and I’m testing Word 2010 with this very post.
Here goes nothing…
The following table lists the variable length subnets from 1 to 32, the CIDR  representation form (/xx) and the Decmial equivalents. (M = Million, K=Thousand, A,B,C= traditional class values)
Mask value: # of
Hex CIDR Decimal addresses Classfull
80.00.00.00 /1 22.214.171.124 2048 M 128 A
C0.00.00.00 /2 192.0.0.0 1024 M 64 A
E0.00.00.00 /3 126.96.36.199 512 M 32 A
F0.00.00.00 /4 240.0.0.0 256 M 16 A
F8.00.00.00 /5 248.0.0.0 128 M 8 A
FC.00.00.00 /6 252.0.0.0 64 M 4 A
FE.00.00.00 /7 254.0.0.0 32 M 2 A
FF.00.00.00 /8 255.0.0.0 16 M 1 A
FF.80.00.00 /9 255.128.0.0 8 M 128 B
FF.C0.00.00 /10 255.192.0.0 4 M 64 B
FF.E0.00.00 /11 255.224.0.0 2 M 32 B
FF.F0.00.00 /12 255.240.0.0 1024 K 16 B
FF.F8.00.00 /13 255.248.0.0 512 K 8 B
FF.FC.00.00 /14 255.252.0.0 256 K 4 B
FF.FE.00.00 /15 255.254.0.0 128 K 2 B
FF.FF.00.00 /16 255.255.0.0 64 K 1 B
FF.FF.80.00 /17 255.255.128.0 32 K 128 C
FF.FF.C0.00 /18 255.255.192.0 16 K 64 C
FF.FF.E0.00 /19 255.255.224.0 8 K 32 C
FF.FF.F0.00 /20 255.255.240.0 4 K 16 C
FF.FF.F8.00 /21 255.255.248.0 2 K 8 C
FF.FF.FC.00 /22 255.255.252.0 1 K 4 C
FF.FF.FE.00 /23 255.255.254.0 512 2 C
FF.FF.FF.00 /24 255.255.255.0 256 1 C
FF.FF.FF.80 /25 255.255.255.128 128 1/2 C
FF.FF.FF.C0 /26 255.255.255.192 64 1/4 C
FF.FF.FF.E0 /27 255.255.255.224 32 1/8 C
FF.FF.FF.F0 /28 255.255.255.240 16 1/16 C
FF.FF.FF.F8 /29 255.255.255.248 8 1/32 C
FF.FF.FF.FC /30 255.255.255.252 4 1/64 C
FF.FF.FF.FE /31 255.255.255.254 2 1/128 C
FF.FF.FF.FF /32 255.255.255.255 This is a single host route
I spend a lot of my time working with Exchange. These days it is primarily Exchange 2003 with some Exchange 2000. In my experience the most missed configuration is the alignment of partition sectors. This can lend to higher actual disk I/O resulting in poor performance. The solution is to use a utility that comes with Windows 2003 SP1 called diskpart.exe.
I often find myself asking the question, “Did you use diskpart to align you partition?”
The most common answers are “I don’t know.” or “What’s that?”. This usually means that the tracks are not aligned, but what if someone else built the server, a vendor, previous employee, etc. Then the question is not so easily answered. How to do check the actual sector alignment? I have not found any easy way to check, until now.
The ability to check the actual starting sector offset (which is the value used to align a partition) is not built-in to diskpart.exe, but it is a part of diskpar.exe. Diskpar.exe is the predecessor to diskpart.exe and was originally included in the Windows 2000 Resource Kit before diskpart.exe was ever available. No big deal, just download the now freely available Windows 2000 Resource Kit from Microsoft’s website and your good to go……not so fast! Microsoft has replaced the original diskpar.exe program with the new version, diskpart.exe. They do claim that the functionality of diskpar.exe is included in diskpart.exe and they are mostly correct, except for the ability to check the current starting sector offset.
What now? Well, to be honest I do have an original copy of the Windows 2000 Resource Kit, and I would love to make diskpar.exe available for download, but I am afraid that will cause me some unneeded attention. So, the best I can say is to dig through your old Windows CDs and find that original copy. Once you do find it, the command to check is very simple:
Here is a sample of the output and what to look for, I used my own workstation that only has one disk and one partition, so this example is simple. (BTW, notice now “infomation” is mispelled…everyone makes mistakes)
—- Drive 0 Geometry Infomation —-
Cylinders = 5169
TracksPerCylinder = 240
SectorsPerTrack = 63
BytesPerSector = 512
DiskSize = 40015503360 (Bytes) = 38161 (MB)
—- Drive Partition 0 Infomation —-
StatringOffset = 32256
PartitionLength = 40015471104
HiddenSectors = 63
PartitionNumber = 1
PartitionType = 7
End of partition information. Total existing partitions: 1
The value we are interested in is “StartingOffset“. Let me explain how to use this number. The default allocation unit size of 4 KB (or 4096 bytes), which can be set when you format the partition, is the best practice per Microsoft. If you use the default allocation unit size of 4096 bytes and have a starting offset that is a multiple of 4096 bytes, then your partition will always align on a 4 KB boundary. If we divide the StartingOffset by our default allocation unit size we should see an integer indicating read/write operations will not cross those sector boundaries.
32256 / 4096 = 7.875
7.875 is not an integer and thus this sector is not aligned. Good thing I do not have an Exchange database on this partition.
For more information on this topic, which is what I use for reference, check out this post on the Microsoft Exchange Team Blog, “You Had Me At EHLO“.
In the event that anyone has any alternate suggestions for checking sector alignment, please post a comment with some details, I would love to find a better way!
In large scale Exchange implementations it is common for the public folder structure to become quite complex. I learned a valuable lesson yesterday with regards to public folder referrals.
When there are multiple public folder stores all part of the same hierarchy each store will have certain folders within the hierarchy that it owns. When a client accesses that folder while connected to a different public folder store there is a referral that occurs so the client can still access the information. This is called public folder referral.
In order for the referral process to work the store process (store.exe) builds a list of all folder items and the other public folder store it will refer to for each.
The lesson I learned is that the only way to rebuild the list of referral partners is to restart the store process, which will also unmount ALL the database stores on that server.