Changing Drive Letter with MSDeploy

I've been doing a lot of migrations from IIS6 to IIS7 recently. This is a handy way of changing the drive letter when using Microsoft Web Deploy to import a site into IIS, say from drive C:\ to D:\

A Full Command Changing the Source Directory of the Archive "msdeploy-site" From "C:\" to "D:\":

Note: That there are no carriage returns, it's one long string.

C:\Program Files\IIS\Microsoft Web Deploy>msdeploy -verb:sync -source:archivedir=D:\msdeploy-site -dest:metakey=lm/w3svc/1863507787 -replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:"

The "replace" here looks for "c:" and changes it to "d:", which will now put the archive under d: when it was originally on c: on the source server.

Excerpt of the relevant part of the command:
-replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:"

Just change the drive letters of "match" with the original drive from the source server and "replace" with the destination drive on the new server.

Now, let's say you wanted to test this command before you ran it. Well then you do this:

C:\Program Files\IIS\Microsoft Web Deploy>msdeploy -verb:sync -source:archivedir=D:\msdeploy-site -dest:metakey=lm/w3svc/1863507787 -replace:objectName="metaProperty",scopeAttributeName="name",scopeAttributeValue="Path",targetAttributeName="value",match="c:",replace="d:" -verbose -whatif

The "-verbose -whatif" will run the command as a test in verbose mode in the command prompt and let you know if there are any issues it runs into and allow you to confirm that the drive letter destination is correct. You can also output this to a file using " > output.txt"

Let me know how this works out for you.

Determining the version of a Microsoft SQL database

This was driving me nuts for a little bit. Once I found out how easy it is, I was flabbergasted.

In SQL 2000

1. Open up Enterprise Manager
2. Right-click on the database
3. Click on Properties
   
4. Click on Options
5. Look under Compatibility Level
   

In SQL 2005

1. Open up SQL Management Studio
   
2. Right-click on the database
3. Click on Properties
   
4. Click on Options
5. Look under Compatibility Level

Database Compatibility Levels:
SQL Server 2008 (100) - SQL Server 2008
SQL Server 2005 (90) - SQL Server 2005
Database Compatibility Level 80 - SQL Server 2000
Database Compatibility Level 70 - SQL Server 7
Database Compatibility Level 65 - SQL Server 6.5
Database Compatibility Level 60 - SQL Server 6.0

"Cannot rename file: Cannot read from the source file or disk."

Do you work in an environment that uses Macs and Windows? Do you have a Windows Server that's being used for file sharing? Are you running into the issue, "Cannot rename file: Cannot read from the source file or disk." or "Cannot delete file: Cannot read from the source file or disk."?

I recently ran into an issue where a user reported that their files were missing from the server. Upon further inspection of the Windows server, I noticed that the files were there, but along with them were a lot of forked files. More information on forked files can be found here:
http://xahlee.org/mswin/mac_windows_file_conv.html

At any rate, I thought it might be a forked file issue, so I removed all unnessary forked files and had the user log out and log back in again. This didn't help. I then checked out the properties of the folder in Windows and noticed that it was reporting 0kb in size. Whoa, wait, I see that these are RAW files and there are about 30 of them all 15MB in size! How can the folder be reporting only 0kb in size? Out of curiosity I tried renaming the folder and noticed a trailing space. Dang! The folder is corrupt because of a trailing space! I tried renaming it, and that confirmed my suspicions, "Cannot rename file: Cannot read from the source file or disk." I was pretty confident this wasn't a HDD issue because there were no errors in the Event Viewer, or RAID software. Microsoft has an article about spaces at the end of the title of files and folders corrupting them, and to call Microsoft Support to correct it:

http://support.microsoft.com/kb/814594

You don't need to do that. You can fix it yourself. Here's how:

In Windows
1. Locate the offending folder
2. Create a new folder
3. Delete all unnecessary forked files if you have any.
4. Move the folders contents to the new folder.
5. Delete the offending folder with the following command:

C:\share\offending-folder\>rd /s "\\?\C:\share\offending-folder "
Note the trailing space above. This will work with other illegal characters for NTFS that corrupt the folder.

You'll be prompted with:

\\?\C:\share\offending-folder , Are you sure
Y/N)?

Press Y

The folder will now be deleted, and access to the files moved to the new folder should be restored.

More information can be found here:
http://blog.dotsmart.net/2008/06/12/solved-cannot-read-from-the-source-file-or-disk/

I've done the following before many years ago, but I would suggest this as a last resort.
1. Get a Live CD, that's running Linux. I think I used STD, or Security Auditor when I last did this.
2. Remove the hard drive from the Windows computer and mount it in Linux with ntfs write capabilities
3. Fix the offending file's name.
4. Put the disk back into Windows computer and boot back into it, and check to ensure the file is renamed correctly and no longer causing issues.

Shrinking the Information Store in Exchange When ESEUTIL Doesn't Do It

I recently ran into a problem where after running ESEUTIL /d, the Information Store was still over the 75GB limit that you can expand to in Exchange 2003 Standard SP2. As a refresher, the total size of the Information Store is the EDB + STM, this is what Exchange looks at when it calculates the size of the Information Store.

I'll list a general outline that most people do to clear up "whitespace" in Exchange.

1. Increase the Information Store limit in Exchange via the registry: http://www.petri.co.il/change_store_size_limits_ex2003_sp2.htm
   
2. Archive and then Delete unneeded mailboxes in Exchange
   
3. Run an offline Defrag: Unmount Information Store and run eseutil /d infostore.edb

At this point, the information store is usually reduced and users and admins are happy. But what if the information store is still too big, or too close to the limit? What if you just want to know the size of "whitespace" on the information store before you do the defrag?


Check to see how much whitespace you have in the information store.

Whitespace is the empty space left over in the information store after data has been removed from it. I like to compare it to someone getting really fat, and then all of a sudden losing a lot of weight. Once this happens, there's a lot of loose skin. The loose skin needs to be tightened up again. Well the "space" between the loose skin is "whitespace", and we need to remove it to make the body tight again. Yes, weird analogy, but it's how I remember it. Let's get to how to check whitespace in Exchange 2003. A good article on whitespace can be found here: http://www.msexchange.org/articles/Exchange-Databases-Disk-Consumption.html

1. Navigate to where you have eseutil installed (if you haven't adjusted the path so you can type it anywhere in DOS)
2. Go into Exchange System Manager ("ESM"), and dismount the target 4store.
3. Run the following command: eseutil /ms infostore.edb > sizecheck.txt
/m = filedump mode
/s = streaming file
> = send the output to
4. Check out the file sizecheck.txt, and look a line that says "Free", note the number, and the last number at the end of the file, but before the line that says "Operation Completed in 'x' seconds", note this number too.
Free: 24093
234234

The first number is the SLV Space Dump for the STM file.
The second number is the Space Dump for the EDB file.

Take the SLV Space Dump File and multiply by 4096 bytes
Take the Space Dump for EDB and multiply by 4096 bytes

ex.
24093 x 4096 bytes = 98684928 bytes = 94.1132812 megabytes of Whitespace
234234 x 4096 bytes = 959422464 bytes = 914.976562 megabytes of Whitespace

914.976562 mb
+ 94.1132812 mb
---------------------------
1009.0898432 mb = 0.9854393 gigabytes ~ 1GB

As you can see, by running this offline defrag check, we would be able to regain about 1GB of space off of our Information Store if we ran a real offline defrag. It's important to note that the commands above do not defrag the Exchange Information Store, it's read-only and only calculating and dumping statistics. But, what happens if we still need more space? One clue to this is by adding up the EDB and STM files and comparing that to the sum of the size of all the mailboxes. If you're lucky, you'll see that the sum of all the mailbox sizes is LESS than the information store size. Hmmm....what's taking up the rest of the space then? The answer is Recoverable Items.

Recoverable Items

Recoverable Items are really deleted-deleted items. You have an email, you delete it, and it goes to the deleted items folder. You empty you're deleted items. You have just deleted-deleted items. But wait...They aren't deleted. Oh, Snap!

In Exchange 2003 Recoverable Items, aka "Deleted Items Recovery" is enabled by default. It's 7 days for deleted email, and 30 days for deleted accounts. If you do the numbers, this can be a whole lot of email that's added up. So, how do you add it all up? You don't have to, Microsoft will do it for you, in the MMC.

1. Go to Performance Monitor
2. Remove all the items there by clicking on "-"
3. Click on the "+" to add an item
4. Find MS Exchange Mail, then choose Total Size of Recoverable Items
5. Click on the paper with the lines on it to give you numbers. This will tell you the size of recoverable items in the information store in kilobytes.

Another old school way, is to open up ESM. Click on Mailboxes. Go to view, and add the "Deleted" tab. You can now see exactly what user tends to have a lot of deleted items, or add all the mailboxes up manually to get the total sum of recoverable items taking up space on the Information Store.


Removing Recoverable Deleted-Deleted Items

Now you know how to find out how much whitespace you have on the Information Store and how much Recoverable Items space is in the Information Store. How do you regain the space on the Recoverable Items? Well, just doing an offline defrag will NOT clear this up. To get this done really soon across the entire information store:
1. Open up ESM
2. Right click on the Mail Store, and go to Properties
3. Find the Limits tab, and click on it
4. Change "Keep deleted items for" and "Keep deleted mailboxes for" to "0" for both. Click Apply.
5. Find the Database tab.
6. In Maintenance Interval area, select "Custom" and change it to the soonest time you'd like.

Summary / Explanation

What will happen now is that the online maintenance will completely wipe all Recoverable Items off the face of the Earth. The place where the Recoverable Items were in the Information Store, now turns into whitespace. You'll know it's done once the online maintenance reports that it's done in Event Viewer. Once done, run an offline defrag to regain space. Hopefully your Information Store is shrank considerably. Don't forget to readjust the Recoverable Items policy back to something helpful (a balance between recovering data, and recovering space). If this happens again, or you see the Information Store growing again, you've outgrown Exchange 2003 Standard and are ready for Exchange 2003 Enterprise or greater. For kicks, while you're running the offline defrag to regain the whitespace from the Recoverable Items, you can refresh ESM while viewing the mailboxes with a viewing column of deleted, and you'll see them shrink before your eyes as you refresh your view.

BTW, if for whatever reason it's not reasonable to do this across all mailboxes, you can adjust the retention policy for individual mailboxes by going in Active Directory Users and Computers ("ADUC") and adjusting the retention policy on a per user/mailbox basis, and then run the online maintenance, rinse, wash, repeat.

Port Report - 2000/XP/2003

Have you ever been in a situation where you have a server that's connecting to another server via a known port that you can track down, but for the life of you can't figure out what application is doing it?

I ran into a server where Surfcontrol now known as WebTrends was reporting that a connection was occurring to another server. There was a rule in Surfcontrol that was blocking the connection. Because of the multiple attempts per second being blocked, it caused the Surfcontrol app to go bonkers and consume loads of CPU resources. I did the usual of netstat -A, didn't see what was connecting to an http port. I checked services, msconfig, run in reg, and taskman. I couldn't identify what was attempting to connect...

PortReporter to the rescue. PortReporter is a small app that is available from Microsoft: http://support.microsoft.com/?id=837243.

You need to pass the WGA test to download it. After that:

1. Unzip the application to a directory you can access, I made one called portreporter on the desktop
2. Run pr-setup.exe
3. Go to Services, and turn on the service called portreporter
4. Go to C:\Program Files\port reporter\ and run port reporter
5. Go to C:\Windows\system32\log files\port reporter\ and you will see your report here.

PortReporter is different than netstat -A, because it provides more information and clearer information. You get to see the application or service name, what ports are being used, what files are being used, PIDs, port mappings, statistics and loaded modules.

Happy port application hunting...