OALGen in CCR clusters
Just a heads up if you’re running Exchange Server 2007 CCR clusters. Moving the cluster resources (using Exchange Management Console or Exchange Management Shell) does not update the OALGen registry settings accordingly. So, if you normally run your CCR clusters active the “A” node, when you move them to the “B” node, OALGen will start throwing errors once per day with an Event ID of 9395 as seen below.
Event Type: Warning
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9395
Date: 7/28/2008
Time: 2:12:30 AM
User: N/A
Computer: xxx
Description:
OALGen is running on a cluster continuous replication (CCR) node which does not have registry value ‘SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\CCRCluserName\EnableOabGenOnThisNode’ or it is not set to this node name. Offline address book generation will not be performed.
I don’t know why the cluster move process doesn’t update the registry accordingly, at least it doesn’t in Exchange Server 2007 SP1 UR1. (I wasn’t able to apply UR2 in June due to other maintenance taking a higher priority and now UR3 is out so I’ll just apply that in August during the maintenance window.)
It’s an easy enough fix though as the error itself indicates. Just navigate the appropriate location in the registry of both nodes in the CCR cluster and make the change. I’ll be creating two registry .REG files and just importing them from now on to make the change even faster (and without error).
If you want to perform detailed logging on the next OAB rebuild, which you will want to trigger manually after updating the registry, simply change the logging level for the “OAL Generator” component to Expert by using the following command at the Exchange Management Shell: Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Expert. You can then manually trigger the OAB update by using this command (assuming that you haven’t renamed the Default OAB): Update-OfflineAddressBook –Identity “Default Offline Address List”. You should see a lot of activity in the Application log on that CCR node with an Event ID 9107 being the last entry for OAL Generator.
Event Type: Information
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9107
Date: 7/28/2008
Time: 7:34:24 AM
User: N/A
Computer: xxx
Description:
Offline address list generation finished.
- Default Offline Address List
Don’t forget to set your OAL Generator logging level back down…it’s typically at Low by default, although can check it by using the Get-EventLogLevel “MSExchangeSA\OAL Generator” command. Use the Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Low command to set logging back down.
Print server migration script
We’ve got a project upcoming where we’ll be moving all of the Windows print queues from four existing print servers (they’re also file servers) to a a single print server. This is a good thing since it will get the load of having the print queues (and all of the various drivers) off of the file servers onto a dedicated server.
Migrating the 500 or so print queues is not so bad, even if done by hand to ensure that the there is only one version (the most current) of each printer driver installed. But how would one go about updating the mappings on all of the client computers? That’s a big task for any organization, especially when you get into the thousands of computers and thousands of users involved.
The attached script will do just that. It should be run as a startup script and will query the local PC to determine what network print queues it is mapped to and remap them accordingly to the new server…just change the server names and off you go.
RemapPrinters2.zip (728 bytes, 1,252 hits)
ADMT updated to version 3.1
If you’ve ever done an AD migration as part of a version upgrade (typically NT 4.0 to something newer) or due to organizational changes, then you’ve probably looked at the Active Directory Migration Tool. I last used it in version 2.0 for an NT 4.0 to 2003 migration and even back then it worked like a charm. My only complaint was that the documentation was pretty sparse and you had to look in more than a few locations to get all of the bits and pieces of knowledge you needed to use it effectively.
A lot has changed since version 2.0, and now version 3.1 has been released with a slew of updates.
- Support for Windows Server 2008
- Support for both 32-bit and 64-bit DCs with the Password Export Server piece
- An update migration guide (hooray!)
Get the updated ADMT utility here, the documentation here and the 32-bit PES and 64-bit PES here.
Note that version 3.1 only supports Windows 2000 SP4 and newer source/target domains. So…if anyone is still running NT 4.0, you’ll need to get ADMT version 3.0, which does support NT 4.0 SP4 source domains (the PDC must be at least SP4, but I’d recommend SP6 from previous experience). You can download ADMT version 3.0 here and the ADMT version 3.0 guide here.
New Update Rollups for Exchange Server 2007
Earlier this week Microsoft released the latest round of Update Rollups for Exchange Server 2007.
- Update Rollup 3 for Exchange Server 2007 Service Pack 1 is discussed in KB 949870
- Update Rollup 7 for Exchange Server 2007 is discussed in KB 953469
Download locations are here:
Both Update Rollups address the issues noted in Microsoft Security Bulletin MS08-039, which was rated as Important, in regards to remote elevation of privileges via a cross-site scripting attack.
An attacker who successfully exploited these vulnerabilities could gain access to an individual OWA client’s session data, allowing elevation of privilege. The attacker could then perform any action the user could perform from within the individual client’s OWA session.
You can get more information about the two vulnerabilities covered in MS08-039 by looking at CVE-2008-2247 and CVE-2008-2248.
Be sure to also examine the Exchange Team’s blog concerning the issue where the Exchange 2007 managed services might time out during certificate revocation checks.
Terminal Services Self-Tuning Monitors, Part 2
As a follow-up to my earlier entry about tuning STT monitors, specifically for Terminal Services…
Either our Terminal Services environment is really, really, really out of the normal (a little bit due to our applications in use, but not excessively so…) or the STT monitor for TS sessions (active and inactive) just plain doesn’t work.
Bottom line, I’ve disabled both monitors after attempting to find an override point for three weeks in a row that would give valid data. No matter what set of thresholds are chosen, like clockwork, at the end of 7 days all of the terminal servers start to issue alerts. I’m marking this one as a bug and hoping for an updated MP in the near future for Terminal Services.
Anyone else have similar experiences?
AD Management Pack update coming in August?
It appears that Microsoft may be planning to release an updated AD MP for Ops Mgr 2007 in August sometime to correct some well-known and no so well-known issues (bugs) with version v6.0.6278.6. I wasn’t able to get any specific details or information about specific items to be corrected though.
Two items are that I think are definitely getting fixes would be the AD Client Update process (AD_Client_Update_DC.vbs) and the AD Client Connectivity process (AD_Client_Connectivity.vbs). From what I’ve seen, you would be lucky to get one of these scripts running smoothly, but not both…sometimes neither depending on the structure of your Active Directory organization. I’m sure there are additional updates and improvements, but those are definitely two big ones. Maybe the documentation will be improved as well to actually list exactly what permissions on what objects are needed for the Run As account to have for the AD MP.
“More Available” DHCP
Last year I upgraded our production AD environment from Windows 2000 Server SP4 based DCs to Windows Server 2003 64-bit R2 SP2 based DCs…yeah, a little bit late.
One of the issues with the previous environment was there was no redundancy in the DHCP implementation. Natively, within what Windows provides, your only real choice for highly available DHCP is to have a DHCP cluster. Since most admins, myself included, prefer to keep all of the network infrastructure services on the DCs (DNS, DHCP, WINS), that makes clustering a no-go…you cannot cluster DCs (more specifically, you cannot cluster DCs and still remain in a supportable configuration should you need assistance from PSS).
There are a few really good hardware based products out there for IP Address Management, such the devices from Bluecat Networks. These appliances have fail-over clustering capabilities and provide DNS and DHCP. But, as was the case with our organization, the desire to stay away from adding extra layers of complexity to the core infrastructure won out over an obviously attractive solution for creating highly available DHCP.
Enter the concept of what I like to call “more available”, or just MA for short. Using a combination of freely available utilities and built-in functionality in Windows Server 2003, you can create a MA solution for DHCP at no cost. A couple of assumptions must be made at this point though:
- You have at least two Domain Controllers in the domain.
- You are willing to install and authorize the DHCP service one at least two of the Domain Controllers.
- You are willing to create a service account that will be a member of the Domain Admins group.
- You are willing to have some divergence (i.e. difference) between the active copy of the DHCP database and the standby copy/copies of the DHCP database on the non-active DHCP servers.
The basic process works like this:
- A wrapper .BAT file is called by a scheduled task on the Domain Controller that is providing DHCP. This scheduled task must be run with credentials that have Domain Admin group membership.
- The wrapper .BAT file first runs a second .BAT file that uses the netsh command to export the DHCP database to a text file. Neat!
- The wrapper .BAT file next runs a third .BAT file that uses the great robocopy utility to copy the entire contents of a certain folder from the Domain Controller that is running DHCP to one or more other Domain Controllers that have DHCP installed and authorized, but not running.
- On each of the target Domain Controllers, a fourth .BAT file is run by a scheduled task (using the same account with Domain Admin credentials). This .BAT file makes a backup copy of the DHCP database on that target Domain Controller and then runs a fifth .BAT file to use netsh to import the DHCP database that was exported from the source Domain Controller. (This task should run later than the one on the source Domain Controller, say 5 or 10 minutes later.)
You can get Robocopy by downloading the Windows Server 2003 Resource Kit tools.
In the attached ZIP file are all of the .BAT files you’ll need to make this work.
- DHCP_processing.bat: The first wrapper file that performs the DHCP database export on the source Domain Controller and then copies the files to the destination Domain Controller(s).
- NETSH_export.bat: Called by the first wrapper file, it performs the export of the DHCP database on the source Domain Controller.
- DHCP_copy.bat: Called by the first wrapper file, it uses robocopy to copy the contents of the folder containing all of the script files and the exported DHCP database to the source Domain Controller(s).
- DHCP_import.bat: Another wrapper file, this one manages the state of the DHCP service on the target Domain Controller and creates a copy of the existing DHCP database before calling the last file to import the DHCP database.
- NETSH_import.bat: Called by the wrapper file on the target Domain Controllers, this one imports the DHCP database.
A few notes to keep in mind to make this work:
- All DHCP servers must be authorized in AD.
- You’ll want to edit the file paths in the provided .BAT files to match your environment.
- The DHCP service on the source Domain Controllers should be changed to Manual start up mode (to ensure that the DHCP service is never accidentally started, which would be a bad thing since you’d have multiple DHCP servers issuing addresses and no single point of reference).
- The service account to be used must be a Domain Admin.
- You should put all of the script files and the robocopy executable in a single folder, such “E:\DHCP\IMPORT_EXPORT” in my environment. Let robocopy copy all of files in the folder to the source Domain Controllers, even though they are not needed (this provides protection for your script files if you lose the source Domain Controller).
- Make sure your network group has configured the network infrastructure (routers and/or switches as required) to allow the IP address of any servers you’re setting this up on as “DCHP helpers”…that will be one less thing to do during a failure event.
In our environment, I have the scheduled tasks running twice daily at 10 AM and 7 PM as this was adequate to capture the vast majority of new DHCP lease issues (i.e. they happen on first and second shift before these times). You can certainly run the tasks as often as you want to reduce the differential between the contents of the two databases.
To put one of the standby DHCP servers in operation, simply stop the DHCP running on the original DHCP server (if it’s available) and start the DHCP service on the standby service. More Available DHCP has now been achieved.
More_Available_DHCP.zip (962 bytes, 989 hits)
l.root-servers.net IP address change
The IP address for the “l.root-servers.net” root DNS changed on November 1, 2007 and officially stopped responding to its old IP address of 198.32.64.12 on May 1, 2008. Of course, I just noticed this…
The new IP address is 199.7.83.42. The full details from ICANN (operator of the l.root-servers.net root DNS:
IMPORTANT: As of May 1st 2008, l.root-servers.net will cease to answer on 198.32.64.12
Following the renumbering of L.ROOT-SERVERS.NET on November 1st 2007 we will cease answering DNS queries on the old IPv4 address of 198.32.64.12 as of May 1st 2008.
The current valid IPv4 address for the server is:
199.7.83.42
We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root “hints” file. This should be updated with the new IP address.
New hints files are available at the following URLs once the change has been formally executed:
ftp://rs.internic.net/domain/db.cache
ftp://rs.internic.net/domain/named.cache
ftp://rs.internic.net/domain/named.root
Make sure you update your your DNS server’s root hints accordingly…
Tweaking Boris’ maintenance mode script
If you’ve got an Operations Manager 2007 deployment, then you’re probably familiar with using maintenance mode. One of the things that puzzled me was why the Health Service Watcher wasn’t put into maintenance mode when you use the GUI console. Boris wrote a FANTASTIC script that lets you put a group of servers completely into maintenance quickly using Powershell.
Being one to never leave things alone, and wanting to customize the functionality a little bit, I did just that. The first customization I wanted to make was to target the script at a different group, in this case one that I created in a custom MP just for those specific servers that were to be put into maintenance mode. I’ve hard-coded that custom group into the script, as you can see, but you could easily change that to be an input. The second customization I wanted to make was to allow you to choose the reason for putting the the servers into maintenance mode. I also hard-coded the RMS name into the script, although you can certainly change that to be a prompted item as well. Seeing as how I would be using the script typically late at night, I built in a bit of logic as well so that if you don’t choose to START or END a maintenance mode period, the script will END it for you. The same logic applies to choosing the reason, if no matching reason is found, the script will pick Planned Other for you.
Anyhow, I don’t take any credit for the original concept…that’s all Boris. Thanks Boris! If you want to get my customized version, grab it below. You’ll need to run this from the normal Powershell instance, not the specialized (with snap-ins) Operations Manager instance…that can be changed though if you like.
Set-MaintenanceMode.zip (2.2 KiB, 825 hits)
New Exchange Server 2007 Technical Content Published
The Exchange Team announced some really good new technical content yesterday for Exchange Server 2007…definitely check it out if you’re currently supporting Exchange Server 2007 or planning to implement it.
- White Paper: Continuous Replication Deep Dive
- White Paper: Planning for Large Mailboxes with Exchange 2007
- Monitoring Without System Center Operations Manager
I’m very happy with the Continuous Replication Deep Dive paper, this is definitely something that should be required reading for every Exchange administrator responsible for Exchange clusters. The Large Mailboxes paper is also a great planning aid that will help out, especially if your organization is planning to use (or already using) Managed Folders and Managed Folder Policies. The Monitoring paper is just outright a good thing to have stashed away in your library, regardless of whether or not you’ve got Operations Manager in your environment…always good to understand the key pressure points of Exchange’s operations.
-
Translator
