Moving Windows Folders With Junction Points

In Dell's infinite wisdom, there was a time when they shipped their Windows 2003 servers with small (10 - 15 GB) system partitions.  It turns out that, over time, that partition would easily be filled by normal operating system updates and various other files.

Fast forward to current times, that partition is now teetering on the abyss with 200 - 300 MB free.  What to do.... what to do.

Well as the title of the article suggests, you can use the wonders of NTFS Junction Points to relocate some non-critical system folders.

Wikipedia has a great write up on the technical details of junction points here.

Now before you go and try to relocated every folder in the Windows directory, an important excerpt from Wikipedia:

Junction points aren't supported by Windows boot process, so it's impossible to redirect certain system folders

In my particular example, Windows Server 2003 doesn't include any method for creating junction points built in.  Lucky for us, Sysinternals has us covered:

http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

So I put that executable in the system folder to allow quick use but you may place it wherever is convenient for you.

In my example I will be moving the ie8updates and ie7updates folders, normally located in the Windows directory.

First, I move (not copy) those two folders to their new final location.  Nothing special here.  A cut and then paste would work or drag drop or whatever.

From there we pop open our command prompt:

Then we will type junction originalpath destination path

As you can see in the screenshot, I redirected those two folders to a replica Windows folder on my D: partition.

And that's it.  Now when Windows goes to look for those folders, it will think they still exist in their original location on the C: parition but actually exist on the D: partition.

Permanent Error During Migration from Exchange 2007 to Exchange 2013

Since our migration schedule is very lax, I am able to record some of the issue I get during our migration process and the fixes for them.

The latest is an error during a user migration from Exchange 2007 to Exchange 2013.  The affected user is added to a batch to migrate but errors out immediately without any items syncing.  The error is as follows:

Migration Error

To paraphrase the image:

MigrationPermanentException:  Active Directory property 'homeMDB' is not writeable on recipient 'path\to\recipient\inAD'.

Great, another bump in my migration path.... right?

Well it turns out that the fix for this particular issue is the exact same as another migration issue I had here.

In short, another AD user object whose security permissions weren't inheriting from it's parent and thus missing the write permission on the homeMDB parameter.

Glad that was an easy fix.  And thanks to MS forums for that fix.

Activesync Not Working After Exchange 2007 to Exchange 2013 Migration

As I continue my journey into migrating to Exchange 2013, I've come across yet another morsel of knowledge to pass along.

In the process of testing my new Exchange server, I selflessly migrated my account over from Exchange 2007 to test that everything was functional.  Much to my dismay, my iPhone stopped receiving email.

I tried rebuilding the email account on the phone and checked every server setting that I could think of.  Everything was set correctly.... or so I had though.

Turns out that the migration to Exchange 2013 left a single Active Directory option unchecked that prevented certain permissions from propagating.  And surprisingly enough, this phenomenon only affected users with Domain Administrator level security.

So here is how I resolved it:

1. Pop open your Active Directory Users and Computers console and ensure that you have the Advanced Features option checked.



Turn on Advanced Features

2. Next, navigate to your affected user and open up Properties, then click the Security tab and select Advanced.



In the Properties of the affected User, under Security, click Advanced

3. In Advanced Security Settings for the user, under Permissions, check the box that says Include inheritable permissions from this object's parent

Check Include inheritable permission from this object's parent

And that's it.  After that, ActiveSync will kick back on for your Admin user.

Full Log Drives in Exchange 2007 | Manually Deleting Log Files

--If you're looking for steps to manually deleting log files in Exchange 2007, skip to the line--

It's always best to monitor your drive space as you manage your Exchange server.  But there are those times, when you come into a situation where you are out of drive space.

A great resource for information regarding full Exchange log drives can be found here.

But to give you a quick snippet from this article that I have used, along with a backstory:

There have been times in the past where our backup system has run into some issues causing backups of our Exchange 2007 environment to fail.  This has subsequently lead to our logs drives to fill up all of the space on the drive.

Typically you have a few solutions in this case:

• Running a backup, either through NTBackup / Windows Server Backup or whatever 3rd party
• Turning on circular logging
• Manually truncating the logs

Most Exchange administrators will agree that running a backup is the best solution, and I would certainly agree.

But in certain cases when a full backup will take too long, you're left with the more drastic options. 

In my case, manual log truncation.

-----------------------------------------------

And to do that, I followed these rough steps:

1. Determine Which Logs are Committed
• Running eseutil /mk <path to .chk file>
• Typically this file is located in your storage group folder




Returned from eseutil


• The information adjacent to Checkpoint will be the last log that has been committed
2. Navigate to the folder containing the logs 
• Inside here, you will find the log file matching the hex value you found above
3. Move any logs prior to that
• Since all the logs prior to that point have been committed to the database, you can move or delete them BUT make note of the following points before you do
• Deleting those logs will remove your ability to restore you Exchange database to a particular point in time
• With that in mind, it's best to move those logs to a drive that has more space (even an external would be better than deleting them)

Exchange 2013 Ports

First post, so it will be something fairly basic involving preparation for Exchange 2013 server installation.

If you plan to run Exchange 2013 and wish to have access to normal public email and/or webmail, you will need to insure that you have the correct ports open on your externally facing firewall.

Exchange 2013 uses the following ports:

Webmail:  443
SMTP:  25

Note however, that the webmail port can be changed to whatever you wish.