I continually run into resistance when discussing the idea of ditching the SAN and using direct attached storage (DAS) for Exchange 2010 implementations. There are a number of reasons that are thrown out there ranging from reliability to managability. However, in my opinion, in most cases, all of those issues can be overcome. At the very least you owe it to yourself and your organization to consider the possibility of saving some large $$ by implemementing multiple data copies in a database availability group (DAG) with DAS rather than using an expensive SAN.
This is one of the best posts I've seen regarding storage for Exchange 2010: http://msexchangeteam.com/archive/2011/01/07/457471.aspx
Wednesday, February 9, 2011
Monday, February 7, 2011
Using Network Monitor Captures in Wireshark
I'm a big fan of packet sniffing for troubleshooting. Just today I was trying to resolve a problem with a SharePoint site behaving inconsistently. Sometimes and only for some computers, the site would not open. After putting a packet sniffer on it, it appears to be a network problem as there are a lot of packets being resent and a lot of duplicate ACKs.
My two favorite programs for packet sniffing are both free:
I was pleasantly surprised today to find out that if you save a capture in Network Monitor, that you can open it in Wireshark. This gives the ability to look at the same data in both tools. Sometimes the way one tool interprets or displays the data is easier to understand when you are looking at something specific.
My two favorite programs for packet sniffing are both free:
- Wireshark (open source)
- Network Monitor (Microsoft)
I was pleasantly surprised today to find out that if you save a capture in Network Monitor, that you can open it in Wireshark. This gives the ability to look at the same data in both tools. Sometimes the way one tool interprets or displays the data is easier to understand when you are looking at something specific.
Tuesday, January 18, 2011
Manually Restoring Registry Files (offline System Restore for XP)
The process in this post is not relevant for Windows Vista or Windows 7. For Windows Vista or Windows 7, boot from the installation DVD and perform a repair. The repair process can perform a system restore.I recently had an unbootable computer that complained about registry corruption on startup. I attempted a last known good for recovery but it didn't work. Which makes sense because last known good works within the registry rather than replacing registry files. A system restore on the other hand replaces the registry files, unfortunately I couldn't get the system bootable to the point of performing a System Restore.
Here is how I replaced the registry files manually:
- Boot the computer from a bootable DVD such as WindowsPE or Ultimate Boot CD 4 Windows.
- Browse to C:\Windows\System32\Config and rename:
- DEFAULT
- SAM
- SECURITY
- SOFTWARE
- SYSTEM
- Change security on C:\System Volume Information to allow Administrator access
- Browse to C:\System Volume Information\_restore{xxxxx}\RPxxx\Snapshot (choose the RPxxx folder based on time of creation)
- Copy the following files to C:\Windows\System32\Config and rename to match step 2.
- _REGISTRY_USER_.DEFAULT
- _REGISTRY_MACHINE_SAM
- _REGISTRY_MACHINE_SECURITY
- _REGISTRY_MACHINE_SOFTWARE
- _REGISTRY_MACHINE_SYSTEM
- Reboot and good to go.
ImageX Gotchas
As of late, ImageX has been my imaging software of choice. Mostly because it is free and I already have it installed. I've been using it to move existing computers to a new drive when a hard drive starts to report errors.
To use ImageX, I attach the drive to my server by using an external USB case. Then run imagex /capture to gather data from the drive. Then I use imagex /apply to put the image down onto the new drive also attached via USB.
The first few times I did this, I was worried the MBR on the new disk would not be configured correctly, but no special preparation is required. Just format the disk ahead of time and mark the partition active.
System Restore Files Not Captured
The files used by System Restore are not captured by the default configuration of ImageX. I was moving to a new drive and then planning on repairing Windows XP. Not such a good plan. This forced me to manually copy system restore registry files from the old drive to the new drive by using a boot CD. However, despite the pain, the system started booting again.
System Restore files are stored in C:\System Volume Information. By default only System has permission to read that folder. To image the files, you may need to modify those permissions. You will definitely need to create a configuration file for ImageX to specify that the folder should be included in the image. Documentation on creating the configuration file is here: http://technet.microsoft.com/en-us/library/cc766147(WS.10).aspx
Don't Forget the Utility Partitions
The hard drive I was capturing data from yesterday had a utility partition installed by the manufacturer in addition to the operating system partition. However, I forgot all about the utility partition and only moved the operating system partition. Then the new drive would not boot.
To get the system bootable, I needed to edit the boot.ini file on the root of C: to point at the single existing partition. The original arc path was pointed at partition 2, I needed to point it at partition 1 as in the example below:
To use ImageX, I attach the drive to my server by using an external USB case. Then run imagex /capture to gather data from the drive. Then I use imagex /apply to put the image down onto the new drive also attached via USB.
The first few times I did this, I was worried the MBR on the new disk would not be configured correctly, but no special preparation is required. Just format the disk ahead of time and mark the partition active.
System Restore Files Not Captured
The files used by System Restore are not captured by the default configuration of ImageX. I was moving to a new drive and then planning on repairing Windows XP. Not such a good plan. This forced me to manually copy system restore registry files from the old drive to the new drive by using a boot CD. However, despite the pain, the system started booting again.
System Restore files are stored in C:\System Volume Information. By default only System has permission to read that folder. To image the files, you may need to modify those permissions. You will definitely need to create a configuration file for ImageX to specify that the folder should be included in the image. Documentation on creating the configuration file is here: http://technet.microsoft.com/en-us/library/cc766147(WS.10).aspx
Don't Forget the Utility Partitions
The hard drive I was capturing data from yesterday had a utility partition installed by the manufacturer in addition to the operating system partition. However, I forgot all about the utility partition and only moved the operating system partition. Then the new drive would not boot.
To get the system bootable, I needed to edit the boot.ini file on the root of C: to point at the single existing partition. The original arc path was pointed at partition 2, I needed to point it at partition 1 as in the example below:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect
Friday, December 10, 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/
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/
Monday, December 6, 2010
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:
Issue #2
The rollup update for Exchange 2010 SP1 was not UAC aware. So, when we ran it, it failed. Quick and easy fix. Go to a command prompt elevated to administrator and run manaully, just like you'd run an exe file.
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 session settings for 'precompile-ManagedBinary' are: View Entire Forest: 'True', Configuration Domain Controller: 'dc.nowhere.com', Preferred Global Catalog: 'dc.nowhere.com', Preferred Domain Controllers: '{ dc.nowhere.com }'
[12/01/2010 21:52:06.0346] [2] Beginning processing precompile-ManagedBinary -BinaryName:'C:\Program Files\Microsoft\Exchange Server\V14\bin\microsoft.Exchange.PowerShell.configuration.dll'
[12/01/2010 21:52:06.0361] [2] Starting: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe with arguments: install "C:\Program Files\Microsoft\Exchange Server\V14\bin\microsoft.Exchange.PowerShell.configuration.dll" /queue /nologo /verbose
[12/01/2010 21:52:06.0517] [2] Process standard output: Installing assembly C:\Program Files\Microsoft\Exchange Server\V14\bin\microsoft.Exchange.PowerShell.configuration.dll
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)
[12/01/2010 21:52:06.0517] [2] Process standard error:
[12/01/2010 21:52:06.0517] [2] [ERROR] Unexpected Error
[12/01/2010 21:52:06.0517] [2] [ERROR] Process execution failed with exit code -1.
[12/01/2010 21:52:06.0517] [2] Ending processing precompile-ManagedBinary
[12/01/2010 21:52:06.0517] [1] The following 1 error(s) occurred during task execution:
[12/01/2010 21:52:06.0517] [1] 0. ErrorRecord: Process execution failed with exit code -1.
[12/01/2010 21:52:06.0517] [1] 0. ErrorRecord: Microsoft.Exchange.Configuration.Tasks.TaskException: Process execution failed with exit code -1.
[12/01/2010 21:52:06.0517] [1] [ERROR] The following error was generated when "$error.Clear();
$fullPath = [System.IO.Path]::Combine($RoleInstallPath, "bin\microsoft.Exchange.PowerShell.configuration.dll");
precompile-ManagedBinary -BinaryName $fullPath;
" was run: "Process execution failed with exit code -1.".
[12/01/2010 21:52:06.0517] [1] [ERROR] Process execution failed with exit code -1.
[12/01/2010 21:52:06.0517] [1] [ERROR-REFERENCE] Id=AllRolesPrecompileManagementBinaries___922e3423e7724c0e8892fe798af5ca08 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[12/01/2010 21:52:06.0517] [1] Setup is stopping now because of one or more critical errors.
[12/01/2010 21:52:06.0517] [1] Finished executing component tasks.
[12/01/2010 21:52:06.0580] [1] Ending processing Install-Bridgehead
Issue #2
The rollup update for Exchange 2010 SP1 was not UAC aware. So, when we ran it, it failed. Quick and easy fix. Go to a command prompt elevated to administrator and run manaully, just like you'd run an exe file.
Saturday, November 6, 2010
Exchange 2010 SP1 on Win 2008 (not as easy as I thought)
Yesterday was my first time to get an install of Exchange 2010 SP1 up and running in a production environment with Windows 2008 as the OS. I ran into a few hiccups and would like to share.
In this particular project, the original OS install was done by someone else. This may have caused part of my confusion as I didn't closely checkout the installation before starting.
This is an Exchange 2003 environment where Exchange 2010 is being added and coexistence will continue for about a week. Exchange 2010 was installed from the Exchange 2010 SP1 download rather than any sort of upgrade.
During the installation, an option exists to install necessary prerequisites. I figured I'd try it out and see. Unfortunately, even on a fully patched Windows 2008 server, I was still forced to download 6 hotfixes and additional chunks of software. I don't recally downloading any of these for Windows 2008 R2. So, it may be OS specific.
The Web server role was added, but did not have the necessary service roles. So, I added everything that was requested by setup. I'm not sure whether the Web server role was added by setup or whether it was preexisting when I started and that is why the setup was off.
When the installation was done, I patched it with rollup 1 for Exchange 2010 SP1. Finally it's time to test.
The first big issue was OWA not working properly on Exchange 2010. It went to a blank page instead of providing the logon screen and no errors were generated. It turns out that the Web server role did not have redirection or static pages enabled. I enabled both and then it worked fine. I'm not sure that the static pages were required as it appeared to be a redirection issue, but since it's a normal option to me, I turned it on.
Again, I'm not sure whether the odd IIS configuration was due to the installation routine or the original setup performed by another tech. However, it is interesting that Exchange setup did not tell me that the redirection was required. And it definitely is for correct OWA logons with forms-based authentication.
When searching related to my OWA issue, I saw that there are a number of people that have various OWA problems after applying Rollup 1 for Exchange 2010 SP1. However, my issue was not related to that.
My second big issue was that no routing group connector was created between Exchange 2003 and Exchange 2010 as should have been. I created it manually (New-RoutingGroupConnector) and all was good. During my multiple install attempts after applying updates, I seleted the option to reuse the existing installation options. I think the requirement to create the routing group connector may have been lost because of that, but I'm not sure.
In this particular project, the original OS install was done by someone else. This may have caused part of my confusion as I didn't closely checkout the installation before starting.
This is an Exchange 2003 environment where Exchange 2010 is being added and coexistence will continue for about a week. Exchange 2010 was installed from the Exchange 2010 SP1 download rather than any sort of upgrade.
During the installation, an option exists to install necessary prerequisites. I figured I'd try it out and see. Unfortunately, even on a fully patched Windows 2008 server, I was still forced to download 6 hotfixes and additional chunks of software. I don't recally downloading any of these for Windows 2008 R2. So, it may be OS specific.
The Web server role was added, but did not have the necessary service roles. So, I added everything that was requested by setup. I'm not sure whether the Web server role was added by setup or whether it was preexisting when I started and that is why the setup was off.
When the installation was done, I patched it with rollup 1 for Exchange 2010 SP1. Finally it's time to test.
The first big issue was OWA not working properly on Exchange 2010. It went to a blank page instead of providing the logon screen and no errors were generated. It turns out that the Web server role did not have redirection or static pages enabled. I enabled both and then it worked fine. I'm not sure that the static pages were required as it appeared to be a redirection issue, but since it's a normal option to me, I turned it on.
Again, I'm not sure whether the odd IIS configuration was due to the installation routine or the original setup performed by another tech. However, it is interesting that Exchange setup did not tell me that the redirection was required. And it definitely is for correct OWA logons with forms-based authentication.
When searching related to my OWA issue, I saw that there are a number of people that have various OWA problems after applying Rollup 1 for Exchange 2010 SP1. However, my issue was not related to that.
My second big issue was that no routing group connector was created between Exchange 2003 and Exchange 2010 as should have been. I created it manually (New-RoutingGroupConnector) and all was good. During my multiple install attempts after applying updates, I seleted the option to reuse the existing installation options. I think the requirement to create the routing group connector may have been lost because of that, but I'm not sure.
Subscribe to:
Posts (Atom)