Posts

Showing posts from December, 2010

Unable to Run New-TestCASConnectivityUser.ps1

I don't normally run the test cmdlets on most Exchange installations. The installation I'm working on this week just installed the Exchange 2010 Management Pack for SCOM. The default installation for this management pack runs the test cmdlets every 5 minutes. By default Exchange 2010 does not have users created to use for the testing done by some of the CMDlets. So, you need to run new-testCasConnectivityUser.ps1 from the scripts folder to create them. This script normally creates users in the "users" container. However, it uses a relative path which fails if there are multiple "users" OUs in your AD structure. To resolve the issue, either make the "users" container unique or edit the script to use the distinguished path "CN=Users,DC=domain,DC=com" However, this guy figured it out first: http://www.snowland.se/2010/01/19/problems-with-new-testcasconnectivityuser-ps1/

Exchange 2010 in a Secure Environment

I'm performing a new installation of Exchange 2010 for a large organization this week and ran into a couple of security related issues that were interesting. This organization limits the processes that can run on computers and when performing the installation, we are domain admins, but not the "Administrator" account. Because we are not the "Administrator" account, UAC applies. Issue #1 Installation failed because the ngen.exe service was disabled. Ngen.exe is used to compile .NET code to make it run faster. This service was disabled as per the security rules. This prevented the original installation and likely would have prevented installing the rollup update as it spent a lot of time compiling .NET code. I'm not sure if this is an issue only when not using Administrator. Obviously in production, I'm not going to test all the possible permutations. The relevant part of the exchange setup log is here: [12/01/2010 21:52:06.0346] [2] Active Directory sessi