Working on a project for a customer. Doing an exchange 2003 to 2007 migration and when you open up the exchange 2007 management console you get a bunch of errors that look pretty ominous. They are validation errors that state the path cannot be the root directory!

After looking into it a little deeper it turns out the customers exchange 2003 storage groups, transaction logs, and databases were stored on different drives but were in the root path of those drives.  Apparently Exchange 2007 is not to keen on that.

The following is what it looked like from the Exchange 2003 console.

I guess the moral of the story is I could move the transaction logs, databases, system paths on the 2003 ide to please the 2007 Mgt console….Or I could just ignore ignore it until the 2003 server is retired.  Since all messaging is flowing properly, I choose the latter…

Scott

I was recently assigned a case by another engineer.  The problem was that a user on XenApp was not able to use an application that they were previously able to. The user would get a generic “Access Denied” by the application which was a .net application published on XenApp. The Administrator account WAS able to run the application

After discussing it further with the engineer who worked on it previously it appears that an update was done to the application prior to this issue arising.

The first thing we tried was to temporarily escalate the permission level of a test user.  We granted a user local administrator rights as a temporary test. The user received the same error.  At this point we knew it was nothing to do with the usual folder/file/registry permissions error since the user still could not access the application.

At this point I turned to an old favorite RegMon from Microsoft.

With Regmon running I was able to launch the application as the user up to the point they were denied access. I reviewed the Regmon log and came across the following:

Why was the user trying to access a dll in another users profile?  I copied that dll “scrrun.dll” to c:\windows

i then registered teh dll using regsvr32 c:\windows\scrrun.dll

Once the dll was registered I then had the normal user test the application. The user was able to access the application=Success!

The moral of the story was that the other administrator applied the update to the application without doing a change user/install.  I bet he wont do that again!

Scott

Paul Robichaux has an awesome article up on windowsitpro http://bit.ly/RmWfS detailing why Microsoft never integrated the two products as has been oft rumored.

Just because something CAN be done, does not mean it necessarily Should!

Scott