About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2016) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Move e2k3 database manually

Today a client asked me to outline the methods for moving his Exchange 2003 EDB/STM database off of his drive that was going bad.  The ESM directed move was stuck at 100% but was not completeing.  The database/STM in question was about 80GB.  What happens is that the GUI says done, but the eseutil in the background is still running, and will be for many hours. 

There is a manual method – unsupported, but it works nicely.

It has been a long while since I did this, so I decided to get it documented and published so others can find this data also.  Keep in mind that this method is NOT supported by the vendor, and YMMV.  However, I have used this many times very successfully.  The reason behind this are the slowness at which database moves occur from within the ESM.  Slow does not describe it!

· Exchange 2003 will move about 4GB per hour on fast drives.

· This method allows you to use file copy which goes much quicker.

· For a 20GB databases, I have used this method to move the databases in less than 1 hour - an ESM move would have taken over 5 hours.

· 15k SCSI drives will go faster than network, iSCSI, or SATA.

KNOW what filenames you are working with.  Exchange expects the filenames to be EXACT.  When you do these moves, copies and renames, make SURE that you are using the names that Exchange is wanting to see.  Check in the ESM BEFORE you start this process.  I suggest screen shots, writing down notes, etc.  Guessing at this information later will not be fun.

1. Dismount databases

2. Stop the stores

3. Copy the edb and stm to location 'x'

4. Crc check the original against location 'x' to ensure file copy successful (use http://www.febooti.com/products/filetweak/screenshots/calculate-hash-crc-checksum.html or similar)

5. Remove the original files from original location. 

    • Suggest a simple rename to keep the files in place.

6. Start Store

7. Mount database.  It will come up and say there is no file, creating a blank will lose data, etc.  Say yes to that.

8. You will have BLANK DATABASES at this point.  ZERO mailboxes.  DO NOT ATTEMPT TO LOGIN.

9. Using ESM standard tools.  MOVE the databases to location "y"

a. This will complete very quickly as you have 5mb, empty databases.

10. Dismount databases

11. Stop store.

12. Move location 'x' files into location 'y'

    • If you did the ESM database move to location ‘x’ then you can just rename the files.

13. Start store

14. Mount databases.

15. Finish.  Login and test.


iPhone VM & Exchange

A day late and a dollar short…

I have been using my iPhone for VM and I had forgotten how I set the mailbox for iPhone support.  So I flailed around a bit and then remembered that Tom Pacyk had the info on his blog….

And now it will be here also, so idiots like me don’t forget where to find the info.

set-ummailbox identity –callansweringcodec gsm

You can use g711 also, but it makes huge files.

Exchange 2010 does MP3 as the default, I believe, audio files for VM so this should not be an issue if you have Exchange 2010.

SQL Change Ports

The Port Change Issue On a project where the SQL team has a policy of changing the SQL port away from the default of 1433?  This does not po...