Problem Scenario:
From Customer Support feedback, we have learned that some customers facing a disaster on one of the Essential Business Server 2008 servers will naturally attempt to clean the servers' residue from Active Directory before starting a replacement/recovery. This is not recommended by EBS and will block the recovery solution for EBS Messaging server since EBS relies on preserved computer objects in Active Directory to proceed with replacement and recovery. Without the original computer objects, Exchange Server recovery will not succeed. Creating new computer objects with the same name as the original EBS servers is not an option and the new computer object cannot be used for replacement.
More specifically, we have seen customers who encounter disaster clean up the residue server objects metadata using ntdsutil. Meta data cleanup will remove the ntds settings object, all replication links, server object, etc. from Active Directory. After that, they often proceed to remove the computer object from the domain partition and start replacement in what they believe is a "clean" environment. Currently, our setup expects both the computer object and the ntdsSettings object to be present in Active Directory before it proceeds with recovery, else Exchange recovery during will fail. We have included documentation to prevent users from doing this, but this seems to still be a natural and common mistake.
Solution:
Any object that is deleted in Active Directory will not instantly disappear, it will instead remain as a TombStoned object in the "Deleted Objects" container of Active Directory. The object will remain there for the tombstone lifetime before it is permanently removed. The Active Directory tombstone lifetime is set to 180 days in EBS 2008 by default.
You can use this feature of Active Directory and first, re-animate the deleted computer object back. The re-animated object will preserve the same GUID, SID, class, SamAccountName, etc. and is effectively the same object, however, a few important attributes will be stripped from it after re-animation. The most important attribute we care about is the group membership attribute (memberOf). Since group membership is a property of the group the object belongs to and not the object itself, this attribute will be lost after reanimation. Hence, after re-animation we will apply the same group memberships to the computer object and proceed with replacement. Depending on the condition of your AD, EBS Messaging replacement may block after domain join, expecting an ntdsSettings server object in the configuration partition. If this happens, simply create a new ntdsSettings object as explained below.
More specifically, this computer object recovery is a three-step process.
1. Re-animate the old deleted computer object:
There are many references online that explain how to recover an Active Directory object that has been tombstoned. I will not attempt to repeat the process here and instead will just include those references. The thing that you must remember is to restore the computer object back to the location it was at the end of EBS setup, which is in the Domain Controllers OU under the default domain partition.
Use the references below to manually restore the deleted EBS Messaging server.
- Manually Undeleting Objects in Active Directory
http://www.petri.co.il/manually-undeleting-objects-windows-active-directory-ad.htm
- Reanimating Active Directory Tombstone Objects
http://technet.microsoft.com/en-us/magazine/2007.09.tombstones.aspx?pr=blog
2. Reapply the group memberships to the restored computer object:
As mentioned above, group memberships are stripped from the object after reanimations because group membership is an attribute on the group the object belongs to, not on the object. Hence, after the computer object is recovered, it must be decorated with at least the group memberships it had by the end of setup. Applying these group memberships will enable replacement to succeed. These groups are:
Domain Controllers
Exchange Install Domain Servers
Exchange Servers
SCE Managed Computers (<ServerName>_MG)
Windows Essential Business Servers
3. If replacement blocks expecting an ntdsSettings object under configuration partition, create it. You do not need to restore the original object from tombstone, and can simply create a new one. To do this, use adsiedit and create a new AD object of class nTDSDSA under the location CN=<EBSMessagingServerName>CN=Servers,CN=<SiteName>,CN=Sites,CN=Configuration,DC=<DomainName>,DC=COM.
You do not need to apply any properties or create any replication channels on this new object; DCPromo will take care of all these settings. Note that the above steps can also be used in restoring any non-EBS Exchange server after an accidental deletion of the server object. The only difference is that you will not need to apply the groups that are EBS-specific (step 2 above).
After these steps you are ready to run EBS server replacement.
Good luck restoring …
Alireza Farhangi
[Today’s post comes to us courtesy of Ping Xu]
Symptoms:
Replacing a network adapter on the Essential Business Server 2008 Security Server may cause inbound and outbound email to queue and not be delivered. Confirm this by checking the message queue on the Security Server:
- Start the Exchange Management Console on the Security Server.
- Click Toolbox.
- Select Queue Viewer under the Mail flow tools category to open the Queue Viewer tool.
- Review the information in the Last Error column. Note whether you have an inbound/outbound message queue and if there is an error similar to "451 4.4.0 DNS Query Failed".
Resolution:
Reconfigure Internal and External DNS Lookups settings by using the Exchange Management Console.
Reconfigure Internal DNS Lookups setting:
- Log on locally to the Security Server.
- Open the Exchange Management Console.
- Select the Edge Transport server in the Result pane, and then select Properties.
- Select the Internal DNS Lookups tab.
- Select your internal Network Adapter in Use network card DNS settings drop down list and click OK.
Reconfigure External DNS Lookups setting:
- Log on locally to the Security Server.
- Open the Exchange Management Console.
- Select the Edge Transport server in the Result pane, and select Properties.
- Select the External DNS Lookups tab.
- Select your External Network Adapter in Use network card DNS settings drop down list and click OK.
Reference:
http://technet.microsoft.com/en-us/library/bb851512.aspx
Special thanks to Susan Bradley for creating a new feed on Twitter for the blog. You can now follow http://twitter.com/EBSblog and receive tweets any time the blog is updated.
[Today’s post comes to us courtesy of Mark Stanfill]
Two new updates are available that allow Windows Essential Business Server 2008 (EBS 2008) to be installed into domains with existing Windows Server 2008 R2 Domain Controllers (DCs).
977193 How to install Management Server of Essential Business Server 2008 in a domain in which one or more domain controllers are running Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;977193
977195 How to run the Preparation Wizard of Essential Business Server 2008 in a domain in which one or more domain controllers are running Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;977195
Both updates are available via Microsoft Update. However, if you do not have network connectivity, they may also be downloaded and installed manually. To apply KB 977195 on the machine you are running the Preparation Wizard on, simply leave the default setting of “Install all available updates (recommended)” checked and select the update button to continue.
For KB 977193, Management Server will automatically download the hotfix during installation if it has Internet connectivity. If you are not able to download files during setup, use the following steps to manually install the update:
- Press SHIFT and F10 together to launch a command prompt.
- Using the command prompt, navigate to where you stored the update.
- Type the following command:
msiexec /update EBS2008-KB977193-x64-ENU.msp
- Follow the prompts to complete the update’s installation. Reboot if prompted. Setup will proceed on restart.
Symptoms
If you do not apply KB 977195 before running the EBS Planning and Preparation Wizards, you will receive the following error message:
The specified domain controller doesn't appear in ServerTable: Servername
If KB 977193 is not applied to the Management Server, setup will fail to proceed with the warning message:
To continue the installation, you must upgrade your Active Directory schema. Run the Schema Upgrade Tool on your schema master domain controller R2DC.contoso.local.
When the tool finishes, click Check Again to continue. If you have already run the Schema Upgrade Tool, wait up to 15 minutes for replication to complete and then click Check Again.
[Today’s post comes to us courtesy of Mark Stanfill]
Microsoft Forefront Security for Exchange Server with Service Pack 2 (FSE SP2) is now available. This is an optional but recommended update for FSE customers, including EBS customers. The download is available here:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2ceb14d4-404b-4d8f-8a21-ebfc71b2e82b
The release notes are available here:
http://www.microsoft.com/downloads/details.aspx?familyid=EE7829A3-0AE8-44DE-822C-908CD1034523&displaylang=en
For EBS installations, additional manual steps may be necessary to complete the installation of this update. If you selected a separate data partition during Messaging Server installation, the steps in this article apply to you. If you have a single partition on your Messaging Server (i.e. only a C: drive), you can skip the steps below and apply the service pack without any additional steps.
Installation Instructions
To install FSE SP2 on an EBS Messaging Server with a separate data partition, use the following steps:
- Download the service pack from the site above and save it locally. Do not run it at this time.
- Extract the contents of the service pack package by running the command: setup.exe /x
- Open the folder you extracted the files to and copy engineinfo.cab to the <DRIVE>:\Windows Essential Business Server\FSEData\Engines folder on your data drive.
- Run setup.exe from the folder you extracted the update to in step 2.
- Follow the prompts of the installation wizard to complete setup.
If you don’t use the steps above…
Manually installing FSE SP2 without first copying engineinfo.cab to the Engines folder on the data drive will result in the following error message when you launch the Forefront Server Security Administrator:
License Information
License Notice
Your evaluation of Forefront Server Security has expired. All actions will revert to Skip: Detect. If you have the product key activate now. To license the Forefront Server please contact your Microsoft sales representative. For more information, see http://go.microsoft.com/fwlink/?LinkId=92354.
Activate Now
To repair this and regain full functionality, use the following steps:
- Copy engineinfo.cab file from C:\program files (x86)\Microsoft Forefront Security\Exchange Server\Data\Engines to <DRIVE>:\Windows Essential Business Server\FSEData\Engines
- Restart the FSCController service.
- Open the Forefront Server Security Administrator and review your settings. You should not receive the activation prompt, and your original license expiration date setting will be restored automatically.
In the Redmond Reader’s Choice Awards newly expanded 2009 survey, Windows Essential Business Server 2008 won Best Group Policy Manager honors in a field of 22 products. Although new to the category, Windows Essential Business Server 2008 came out on top with 15.7 percent of the votes. If that’s not enough good news, Windows EBS also came in third for Best Storage-Management Product in a field of 29 products.
In past years the 2009 Redmond Reader’s Choice Awards had become almost routine, so the editors chose to spice it up a quite a bit in 2009, adding new participants, including new products and updating to the latest version of the products included. The survey polled for 52 separate awards in categories including Network & Systems Management, Installation & Deployment, Administration, Security, Training & Certification, Storage & Backup and introduced a new category about Virtualization.
Congratulations to ALL of the Redmond Magazine Reader's Choice Awards winners, especially the 19 Microsoft Award winners!
While Windows Essential Business Server 2008 (Windows EBS) Security Server can be installed as the single perimeter security solution it is common to have it coexist with existing security solutions like hardware firewall on the perimeter. In this configuration, Forefront TMG is the “back end firewall” to the existing “front end” firewall, providing a defense in depth setup.
In this case, there are few choices available – this blog post calls out the decision points and provides an outline of the activity for each decision:
1. Configuring the network to support two security devices for defense in depth.
The introduction of a backend firewall requires the front end firewall to be on a separate subnet than the rest of the local network. There are two ways to easily achieve this. The selection will be driven by your knowledge of the existing firewall and the number of devices in your network.
a. (default) Take over internal IP address of front end firewall and create a new subnet between the front end firewall and EBS Security Server. Windows EBS Setup automatically defaults the internal IP of Security Server to be the internal IP address of existing (front end) firewall. The only remaining activity is to reconfigure your front end firewall for the new subnet. Refer to the documentation of your front end firewall to accomplish this task.
b. Create a new subnet for existing clients to use with EBS Security Server, leaving the front end firewall networking configuration untouched (you still need to update any rules that refer to old server IPs for any servers you publish). This requires reconfiguration of all the clients and servers in your network to use EBS Security server as the default gateway. To accomplish this task, you need to edit the internal IP address of Security Server during Setup to be the new gateway IP address. You will also need to change the default gateway on all the machines that have a static IP address in your network and update the gateway property on your existing DHCP server. The latter is automatically done if you decide to install the DHCP role on EBS.
2. Choice of security level enforced by EBS Security Server
Based on the capabilities of your existing front end firewall, you can reduce the security level enforced by EBS Security Server, using the tool introduced by Feature Pack 1 for Windows Essential Business Server 2008. The various levels and security features for each level are documented at the Change the Security Level topic in the Windows Essential Business Server Technical Library. This feature pack id downloaded when you check for updates during installation of Windows EBS or you can download it from Microsoft Download Center.
3. Keeping the two firewalls in sync with each other
The default configuration for Windows EBS configures the EBS Security Server to :
- publish Remote Web Workplace & Exchange services,
- allow internet access for all users, and
- configures firewall rules for essential network services like DNS to function.
If you chose the security level for EBS Security Server to be medium-low or higher, you need to identify other applications your users will access from outside and publish those servers/services using the Server Publishing or Web Publishing wizard; you may also need to add access rules for any line of business application that needs outbound access on protocols other than HTTP or HTTPS protocol, using the “Add new access rule” wizard. On the front end firewall, you also need to update the firewall rules to forward the traffic to EBS Security Server. You may need to republish services like Remote Web Workplace and Exchange services like Outlook Web Access from EBS Security Server in your existing firewall.
If you chose security level for the EBS Security Server to be “low”, you do not need any changes in EBS Security Server. You need to publish services like Remote Web Workplace and Exchange services like Outlook Web Access directly in your front end firewall. For all the default configuration details, refer to the Security and Protection section in the Windows Essential Business Server Technical Library.
4. Choices with site to site VPN configurations (if applicable)
Site to Site VPNs are commonly used to provide connectivity to remote branches. The branch network is connected using a VPN tunnel into the VPN device (typically the front end firewall) – with EBS Security Server installed behind the existing front end firewall, you have 2 choices:
a. A simple option is to continue to terminate VPN at the front end firewall and configure EBS Security Server to route traffic between the branch networks and your internal network. The steps involved are:
i. Create an “Address Range” object for each branch subnet.
ii. Add a Network rule of type “route” and place it above default NAT rule.
iii. Add an array access rule allowing traffic between branch network address range and internal network .
With this configuration, you can now access internal network resources from remote branch subnets and vice versa.
b. An advanced option is to terminate your VPNs in EBS Security server – this requires reconfiguring the existing firewall to pass through traffic to EBS Security Server and establish VPN tunnel in the EBS Security Server with the branch device. You can use the “Create Site to Site VPN connection wizard” in Forefront TMG console to accomplish this task. Refer to VPN Consortium for compatibility of VPN devices.
Hope this helps organizations, partners, and administrators who want to integrate their Security Server in Windows EBS 2008 into a network with an existing firewall. Let us know if you would like more detailed steps for any of these sections!
Downloads :
Feature Pack 1 for Windows Essential Business Server 2008.
References :
Security and Protection section in the Windows Essential Business Server Technical Library.
Related posts :
New feature : Adjust the level of protection provided by Security Server in Windows Essential Business Server 2008
Site to site VPN and Windows Essential Business Server
As always, your comments and questions are welcome!
Kannan C Iyer
Program Manager
Windows Essential Business Server
Microsoft Corporation
[Today’s post comes to us courtesy of Mark Stanfill]
When trying to use the Check Out (or Check In) feature of Windows SharePoint Services (WSS) 3.0 published behind TMG in a default EBS installation, checkout fails with the error below:
Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217)
Resolution
To allow documents to be checked in and checked out through WSS 3.0 behind TMG, you must disable normalization in order to allow the URL that WSS specifies. To do this, use the following steps:
- Log on to the Management Server or Security Server as an administrator and launch Forefront TMG Management console.
- Select Firewall Policy in the console and select the Allow Authenticated Users to access Sharepoint services rule.
- Right-click on the rule and choose Configure HTTP.
- Uncheck Verify normalization.
- Click OK to save changes.
- On the left pane, click on Monitoring and click on the Configuration tab. Refresh the screen until you see that the status is Synced.
- Log out of RWW and log back in to check the document out.
[Today’s post comes to us courtesy of Mark Stanfill]
On EBS Management Servers with the Windows Essential Business Server SharePoint Add-in installed, you may see the an event similar to the one below in the Application Log in Event Viewer every 5 minutes:
Log Name: Application
Source: Windows SharePoint Services 3 Search
Event ID: 2436
Task Category: Gatherer
Level: Warning
Keywords: Classic
Description:
The start address <sts3://companyweb/contentdbid={75d6eac6-cb0e-4cac-9f7e-243adc1f7fe4}> cannot be crawled.
Context: Application 'Search index file on the search server', Catalog 'Search'
Details: The object was not found. (0x80041201)
Cause
This error occurs because the Gatherer service attempts to locate content at the root of the published SharePoint site by default. The EBS SharePoint Add-in publishes all content to the /SharePoint virtual directory by default. This error appears after installing Windows SharePoint Services 3.0 SP2 (KB953338).
Workaround
The error can be safely ignored. Content is indexed successfully for the rest of the SharePoint site. If you do not want the errors to appear, use the following steps:
- Log on to the Management Server as an administrator.
- Open SharePoint 3.0 Central Administration from START\All Programs\Administrative Tools.
- Select the Application Management tab and then select Define managed paths.
- Verify that the URL selected for Web Application is correct.
- Enter a forward slash (‘/’) character under Path: and change the Type: to Explicit inclusion. Click OK to save the settings.
- Select the Application Management tab again and then select Create site collection.
- Verify that the URL selected for Web Application is correct.
- Type an appropriate description for the Title:.
- Verify that Web Site Address is set to ‘/’.
- Choose Blank Site under Template Selection.
- Type an appropriate entry under Primary Site Collection Administrator.
- Click OK to save settings.
[Today's post comes to us courtesy of Alok Goyal]
My name is Alok Goyal and I am a part of the Essential Business Server (EBS) team. Today, I wanted to talk about a new document I posted on the Microsoft Connect site. The document is titled "Site to site VPN and Windows Essential Business Server." It talks about how to establish site to site VPN tunnel in an Essential Business Server environment. The core audience of this document is the network engineers who need to configure and test a site to site VPN tunnel between the two network sites when Essential Business Server is present in the environment.
A site to site VPN tunnel establishes a secure channel between the two sites via the Internet. It enables organizations to extend their networks across low cost Internet connections without compromising the security. It establishes an authentication mechanism at both ends of the VPN tunnel by encrypting all the data.
Many of you have been using Windows Essential Business Server in the mid-sized marketplace as it boosts productivity and growth. It helps view, deploy, manage and administer applications from one central point. Windows Essential Business Server includes Security Server which protects your network through a Threat Management Gateway (TMG) component. It acts as a software firewall between your network and the outside world. It also includes site to site VPN functionality based on IPsec tunnel mode protocol.
There are two main ways you can install Essential Business Server:
1. Replace your existing firewall with the Essential Business Server Security Server
2. Install Essential Business Server Security Server behind your existing firewall
Essential Business Server team recommendation is to choose option 1) as it is the best choice for our customers. It reduces complexity and lowers down your cost of maintaining the additional firewall. However, sometimes this transition is difficult for some of you. However, you still can choose option 2) when you install EBS.
That said, in a site to site VPN scenario, option 2) becomes very tricky as you get two more options:
a. Terminate your existing site to site VPN tunnel at your existing firewall
b. Terminate your existing site to site VPN tunnel at Essential Business Server Security Server
Option a) is advanced and more complex than option b). The "Site to site VPN and Windows Essential Business Server" document talks about a generic approach and discusses how you can use option a) after installing Essential Business Server in your environment. It starts with a network configuration as an example and helps you understand the required steps necessary for a site to site VPN tunnel to work. In addition to that, the document provides step by step instructions for configuring the IPsec VPN tunnel between the ISA server and one of the IPsec compatible gateways such as Netscreen 25 device when Essential Business Server is present in the environment. The document assumes that you have a computer on the branch office network running ISA server. As you understand, it is impossible to foresee every possible combinations as you may use any of the available industry leading gateways providing site to site VPN technology. The example listed in this document is for reference only and illustrating only the concepts. Also, we recommend you to go to www.vpnc.org to check for any firewall/gateway compatibility issues.
Download Full Document
To download this document, go here.
If you are not already registered with Microsoft Connect, you may need to do so (it's a simple process and it's free).
Supporting Documents
A few other great artciles on how to configure VPN tunnels include:
http://www.isaserver.org/tutorials/Creating-VPN-ISA-Server-2006-Firewalls-Main-Branch-Office-Part1html.html
http://www.cisco.com/en/US/docs/security/asa/asa71/getting_started/asa5500/quick/guide/sitesite.html
http://www.firewall1.nu/docs/Watchguard_V60_and_Fortigate_60_VPN.pdf
[Today’s post comes to us courtesy of Mark Stanfill]
When trying to browse through the OWA Address Book on a default EBS configuration, the first page of the address book will load, but attempts to browse to subsequent pages will fail with the error:
Could not connect to a directory server. If the problem continues, contact
technical support for your organization.
This error occurs because the default “Microsoft Exchange Server Publishing: Outlook Web Access” web site publishing rule is configured for link translation by default. This allows the first page to load successfully when the internal OWA URL is translated, but subsequent pages are unable to connect as the cookie session fails to query the correct URL. Disabling the mapping for the OWA web site publishing rule will remedy this situation, and does not otherwise affect OWA functionality.
https://remote.tailspintoys.com/owa/?ae=Dialog&t=AddressBook&a=PickRecipients
Resolution
To allow OWA to show the entire address book on EBS, use the following steps:
- Log on to the Management Server and load the Forefront TMG Management console. Connect to the Security Server if needed.
- Navigate to the Firewall Policy node on the left-hand side of the console and highlight the “Microsoft Exchange Server Publishing: Outlook Web Access” web site publishing rule.
- Right-click the “Microsoft Exchange Server Publishing: Outlook Web Access” web site publishing rule and choose Properties.
- Select the Link Translation tab.
- Select the Configure button.
- Highlight the entry with your internal Messaging Server FQDN and external FQDN and select Remove (there is only a single entry present by default). Click OK and OK again to save the setting. Important: Do not modify any other link translations for any other rules.
- Select Apply in the main TMG window.
- On the left pane, click on Monitoring and click on the Configuration tab. Refresh the screen until you see that the status is Synced.
Related Issue – The page cannot be displayed/HTTP 500 for contact properties
After configuring the rule above, you may receive the following error trying to access the properties of a user or contact:
Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217)
TMG logging will show a corresponding error. The relevant portion is highlighted below:
Blocked by the HTTP Security filter: URL normalization was not
This error occurs because of the format of the URL. The TMG HTTP Security filter identifies this as suspect traffic and blocks it. To resolve this error, take off URL normalization off for the OWA publishing rule (again, don’t modify other rules).
- Log on to the Management Server and load the Forefront TMG Management console. Connect to the Security Server if needed.
- Navigate to the Firewall Policy node on the left-hand side of the console and highlight the “Microsoft Exchange Server Publishing: Outlook Web Access” web site publishing rule.
- Right-click the “Microsoft Exchange Server Publishing: Outlook Web Access” web site publishing rule and choose Configure HTTP.
- In the Configure HTTP policy for rule dialog, de-select Verify normalization. Click OK to return to the main dialog.
- Select Apply in the main TMG window.
- On the left pane, click on Monitoring and click on the Configuration tab. Refresh the screen until you see that the status is Synced.
After disabling ‘verify normalization’:
Special thanks to Austin McCollum for first documenting this behavior and the work-around.
[Today’s post comes to us courtesy of Shawn Sullivan]
The Autodiscover service, which allows Outlook 2007 and Windows Mobile 6.1 ActiveSync clients to obtain mailbox connection settings with little user intervention, is not configured by default in EBS 2008. In order to open the Autodiscover service to both internal and external clients, you must follow several steps on both the Messaging and Security servers:
- Configure the correct DNS records that will point external clients to the proper URL for the autodiscover service.
- Install a trusted SSL certificate on the Forefront TMG web listener or distribute the default EBS certificate.
- Create a Web Publishing rule in Forefront TMG to allow the autodiscover requests from your external clients to reach the Messaging server.
- Add the proper internal and external URL parameters to the Autodiscover virtual directory on the Messaging server.
This post will cover each step in detail, covering several common configurations mistakes.
Public DNS and Certificates
In order to know how you should configure your external DNS records for autodiscover, you must understand how Outlook 2007 and Windows Mobile 6.1 clients will attempt to locate it. In the following example, user@contoso.com is creating a new Outlook 2007 SP1 profile from their brand new laptop connected to their home network. Outlook will take the second half of their email address, contoso.com, and do the following:
- Attempt to resolve and connect to https://contoso.com/autodiscover/autodiscover.xml. If it cannot, it will then:
- Attempt to resolve and connect to https://autodiscover.contoso.com/autodiscover/autodiscover.xml. If it cannot, it will then:
- Attempt to resolve the SRV record for _autodisover._tcp.contoso.com and get a hostname in return, such as remote.contoso.com. It will then attempt to resolve and connect to https://remote.contoso.com/autodiscover/autodiscover.xml. If it cannot, then at this point your connection has failed and you would have to configure Outlook Anywhere manually.
For the connection to be successful, the URL that Outlook chooses must be tied to a valid certificate that Outlook trusts with a subject name that matches the URL. To test this, browse either OWA or RWW from your client machine using the Security server’s public URL. If you receive one or all of the following warnings, then Autodiscover will fail on this client (as well as Outlook Anywhere, ActiveSync, and Connect to computer through RWW).
During the Security server setup, you are asked to specify the name of the remote web portal that TMG will use to publish your Exchange virtual directories and Remote Web Workplace.
A certificate is then created by the Enterprise Root CA using this name that you specify as the Subject Name. The certificate is then placed in the External Web Listener in ForeFront TMG (not IIS on the Management server). This configuration can result in a failure on the client for one or more of the following reasons:
- Client machines who are not joined to the domain will not trust this certificate
- You have entered a domain prefix during setup, such as remote.contoso.com, that contradicts the autodiscover ‘A’ record that you have registered publicly. In this case, Outlook resolves autodiscover.contoso.com, connects to your site, and receives certificate error because remote.contoso.com is presented instead.
- An SRV record has not been created which points to the FQDN, including the prefix.
For EBS, we recommend creating an SRV record for your domain. This will require Outlook 2007 SP1 or later to take advantage of the record:
| Service | _autodiscover |
| Protocol | _tcp |
| Port | 443 |
| Host | RemoteName (for example, remote.contoso.com) |
In this example, you must have a public ‘A’ record for “remote” that resolves to your Security server’s public IP address.
Internal Clients
[This section is included for reference only. No action is normally needed: Autodiscover works out of the box in EBS.]
All internal Outlook 2007 clients who access the Autodiscover service should be first joined to the domain. Then, instead of using DNS directly, they will query Active Directory for the Service Connection Point object that will return the proper URL:
CN=ServerName,CN=Autodiscover,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local
NOTE: The URL will point to your Messaging server’s internal Fully Qualified Domain Name. This will match the Subject Alternative Name of the Exchange certificate installed on the Default Website of the Messaging server. This is why your internal domain clients will not receive a certificate warning when they connect. You do not need to make any changes in your EBS environment for this to work.
Create the Autodiscover Web Publishing Rule
You must manually create a rule to allow Forefront TMG to Web Publish the Autodiscover traffic from external clients to your Messaging server. Unlike OWA, RWW, and ActiveSync, this is not configured for you by default. Like the other virtual directories that we publish through TMG, the rule that we will create uses SSL bridging to connect the external client to the Autodiscover service; meaning that the client will make one SSL connection to TMG while TMG makes its own SSL connection to the Messaging server. This will utilize the same ports, IP addresses, and certificates that we already have in place.
Open the Forefront TMG console, right-click on Firewall Policy, choose New > Web Site Publishing Rule
Choose Allow for Select Rule Action
Choose Publish a single Web site or load balancer for Publishing Type
Choose Use SSL to connect to the published Web server or server farm. The Messaging server already has an SSL certificate installed on the Default Website that hosts the Autodiscover virtual directory.
For Internal Publishing Details, enter the hostname of the Messaging server. Do not enter the fully qualified domain name.
Enter /autodiscover/* for the website path and check the box for forward the original host header.
For Public Name Details, leave This domain name (type below) selected. Enter the public FQDN that you registered in the Public Name field. Do not change the path.
Click the drop-down menu, select External Web Listener, and click Next.
Select Basic Authentication in the drop-down menu for Authentication Delegation.
Accept the default All Authenticated Users selection for User Sets.
Apply the changes.
On the left pane, click on Monitoring and click on the Configuration tab. Refresh the screen until you see that the status is Synced. Once it is, the rule that you just created is now in place.
Add InternalURL and ExternalURL to Autodiscover
You must manually assign the proper internal and external URL configuration to the Autodiscover virtual directory on the Messaging server. As mentioned before, both external and internal Outlook 2007 clients use the Autodiscover service, so these URLs must be browsable from their respective network locations. Specify the public FQDN for ExternalURL and the internal FQDN for InternalURL.
For example, your external FQDN is remote.contoso.com and your internal FQDN for the Messaging server is messaging.contoso.local. In this case, open the Exchange Management shell and run the following command:
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –ExternalURL https://remote.contoso.com/autodiscover/autodiscover.xml -InternalURL https://messaging.contoso.local/autodiscover/autodiscover.xml
You can verify that the settings are correct by running the command:
Get-AutodiscoverVirtualDirectory | ft *url*
NOTE: Replace the ExternalURL and InternalURL in this command with the actual ones you want to use. Do not copy and paste the command from this blog post into PowerShell.
[Today’s post comes to us courtesy of Mark Stanfill]
System Center Essentials 2007 SP1 (SCE 2007) included with Essential Business Server 2008 now fully supports Windows 7 and Windows Server 2008 R2 clients, but there are a few manual steps that must be performed before these clients can be managed from the SCE Console. Because the SCE engine is derived from System Center Operations Manager (SCOM), it is important to be familiar with the supportability statement in KB 974722 as well.
Step 1: Install the SCE Management Packs
First download and install the Windows 7 and Windows Server 2008 R2 Management Packs. These are the same as the SCOM MPs. There are two MPs to download:
Windows Client 2000/XP/Vista/Windows 7 Operating System Management Pack for Operations Manager 2007
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f55f1803-eae6-4ed5-b2d2-9e1adf98e325
Windows Server Operating System Management Pack for Operations Manager 2007
http://www.microsoft.com/downloads/details.aspx?FamilyId=3529D233-5E3E-4B51-8F66-5D6F27005EC3&displaylang=en&displaylang=en
Once you have downloaded and extracted the Management Packs, import them in the System Center Console under the Administration node (aka the gear icon) by select Management Packs and then clicking on Import Management Packs…, selecting the appropriate MP files (Microsoft.Windows.Client.Win7.* and Microsoft.windows.client.library.mp) and then choosing Open.
Step 2: Prepare the Client Deployment Folder
SCE 2007 does not support deploying 64-bit Windows 7 clients through the Discovery Wizard (see below). The clients must be deployed manually. 32-bit Windows 7 clients and down-level clients (i.e. Vista and below) can continue to be deployed through the Discovery Wizard.
To distribute the SCE Agent (System Center Operations Manager 2007 Agent), copy the following files to a new share on the Management Server:
- %ProgramFiles%\System Center Essentials 2007\AgentManagement\amd64\*
- %ProgramFiles%\System Center Essentials 2007\SCECertPolicyConfigUtil.exe
- %ProgramFiles(x86)%\System Center 2007 Hotfix Utility\Q954049 (Copy the entire directory)
Share the folder and ACL appropriately.
Step 3: Install the Agent on the Client Machine
Log on to a Windows 7 client machine using an account with rights to install the software. For the steps below, you will need to know the Management Group name for your installation. This will be the name of your EBS Management Server with _MG appended. For example, the Management Group for MGMT.contoso.local will be MGMT_MG. You can confirm this by opening the SCE Management Console and verifying the name after “System Center Essentials – “ in the title bar of the window.
Option 1 – Manual Install
- Connect to the share created in Step 2 above and double-click on MOMAgent.msi.
- Follow the prompts, using the appropriate Management Group name and Management Server name. Important: you must specify the FQDN (e.g. mgmt.contoso.local) for the Management Server name. Do not use the NetBIOS name or IP address.
- Use all the default values for the installation and complete the wizard.
- Double-click on SCECertPolicyConfig.msi to install it.
- Stop the OpsMgr Health Service service on the client machine.
- Install the SCE Agent KB hotfix by typing the command from an elevated command prompt:
\\managementservername\share\Q954049\SetupUpdateOM.exe /amd64MSP:Q954049-x64.msp /agent
Where managementservername is the name of the server, and share is the name of the share.
- Follow the wizard’s prompts to install.
- Restart the OpsMgr Health Service.
- Optional: On the client, run “GPUpdate /force” from an elevated command prompt, reboot the client machine, run Control Panel\Windows Update\Check for updates, then run wuauclt /reportnow from an elevated command prompt to force the client to immediately register with SCE.
Option 2 – Automated Install
The steps above can be automated for use in batch files or login scripts by specifying variables as command line-parameters. Use the following commands to automate the installation. The following variables are assumed:
- server – the NetBIOS name of the Management Server
- share – the name of the share created in step 2 above
- MG_Name – the Management Group specified above (server_MG by defualt)
- FQDN – the FQDN of the Management Server
The commands are long, so they will wrap. Individual commands are separated by a blank line:
msiexec /i \\server\share\MOMAgent.msi /qn MANAGEMENT_GROUP=MG_Name MANAGEMENT_SERVER_DNS=FQDN ACTIONS_USE_COMPUTER_ACCOUNT=1
msiexec /i \\server\share\SCECertPolicyConfig.msi /qn
\\server\share\Q954049\SetupUpdateOM.exe /silent /amd64MSP:Q954049-x64.msp /agent
FAQ
Q: Can I deploy via a GPO?
A: Not easily. It is not possible to specify command line parameters through a GPO, so a transform would be required for a fully automated install.
Q: I successfully deployed the client to my 64-bit Win7 client, but it does not show up the Computers node or the operating system is not listed. What happened?
A: The client has not reported back to WSUS and SCE with its inventory yet. It will automatically report back to the server overnight. Alternatively, you can reboot the client and then manually trigger a Windows Update detection in order to force it to report back to SCE.
Q: I get an “RPC Server is not available” error when trying to install to a newly joined 32-bit Windows 7 client.
A: It’s possible the client has not yet applied Group Policy. Log on to the client, run gpupdate /force from an elevated command prompt, reboot the client, and try deploying the agent again.
Q: I’m running SCE in a non-EBS environment. Do the steps in this article apply to me?
A: In general, yes. All component products shipped with EBS are identical to the stand-alone versions.
Q: What hotfixes need to be installed on the Management Server?
A: KB 974722 details a number of hotfixes. KB 951327, KB 953290, and KB 954049 should already be installed if the server has been receiving updates via Windows Update (KB 954049 is installed during EBS setup). KB 952664 does not apply as it is x86 only. KB951116 is for SCOM only, and does not apply to SCE.
Q: The agent successfully deployed, but now my Win7 client shows up with an Operating System of Windows 0.0 under the All Clients group.
A: The client has not reported its inventory back to WSUS and SCE yet. Wait overnight or run wuauclt /detectnow && wuauclt /reportnow on the client to force it to update WSUS.
Q: The client MP has 9 .MP files in it. Which ones do I need to install?
A: You only need to install the Microsoft.Windows.Client.Win7.* and the Microsoft.windows.client.library.mp Management Packs. The other MPs are already installed. You won’t harm anything by re-importing the existing MPs, but it is an unnecessary step.
Q: Why can’t I connect via TS to my Win7 clients? XP and Vista clients work fine?
A: Although SCE creates a GPO to enable RDP access through the Windows Firewall, Win7 domain-joined clients do not have Remote Desktop enabled by default. To connect to these clients via RDP, you need to explicitly enable it either manually or through Group Policy (Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections\Allow users to connect remotely using Terminal Services). A logical place to enable this is on the “SCE Managed Computers Group Policy (SERVERNAME_MG)” policy.
Why this is necessary
The security hardening of Windows 7 won’t allow the MOMAgentInstaller executable to modify the Windows Firewall. Attempting to deploy the SCE Agent to a 64-bit Win7 client via the Discovery Wizard will result in the following error:
The MOM Server could not start the MOMAgentInstaller service on computer “<computername>” in the time.
This service is used to perform configuration operations on the computer before the Microsoft Operations Manager agent can be configured.
Operation: Agent Install
Error Code: 0x80070102
Error Description: The wait operation timed out.
On the client side, an error will be logged in the Application Log:
Log Name: Application
Source: Application Error
Date: 10/28/2009 1:47:38 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Win7-PC.adventure-works.local
Description:
Faulting application name: MOMAgentInstaller.exe, version: 6.0.6278.0, time stamp: 0x47b70fc7
Faulting module name: ole32.dll, version: 6.1.7600.16385, time stamp: 0x4a5be01a
Exception code: 0xc0000005
Fault offset: 0x000000000003245a
Faulting process id: 0xbcc
Faulting application start time: 0x01ca580fe1ba652a
Faulting application path: C:\Windows\422C3AB1-32E0-4411-BF66-A84FEEFCC8E2\MOMAgentInstaller.exe
Faulting module path: C:\Windows\system32\ole32.dll
Report Id: 204e3708-c403-11de-8ed9-00155d44602d
The COMPUTERNAMEAgentMgmt.log in %ProgramFiles%\System Center Essentials 2007\AgentManagement\AgentLogs on the Management Server will show an entry similar to this (the HResult: 8000ffff entry is diagnostic):
05:34:41 PM : CServiceModule::Init : m_bService is set to true HResult: 0
05:34:41 PM : CServiceModule::Start : Service flag is set
05:34:41 PM : CServiceModule::SetServiceStatus : State: 2, Error: 0
05:34:41 PM : CServiceModule::SetServiceStatus : State: 2, Error: 0
05:34:41 PM : RegisterFile : Before LoadLibrary
05:34:41 PM : RegisterFile : After LoadLibrary
05:34:41 PM : RegisterFile : Before GetProcAddress
05:34:41 PM : RegisterFile : After GetProcAddress
05:34:41 PM : RegisterFile : After FreeLibrary
05:34:41 PM : RegisterFile : Success return
05:34:41 PM : RegisterFile : WaitForSingleObject return HResult: 0
05:34:42 PM : ConfigureWindowsFirewallExceptionForApp : AddRemoveAppForWindowsFirewallException failed: HResult: 8000ffff
05:34:42 PM : CServiceModule::SetServiceStatus : State: 1, Error: 0
05:34:42 PM : CServiceModule::Handler : ConfigureWindowsFirewallExceptionForApp failed while adding exception HResult: 8000ffff
[Today’s post comes to us courtesy of Vikramjit Singh, Stephen Li, and Mark Stanfill]
Updated 10/29/2009 to reflect IT Environment Health Scanner information.
If you are preparing to install EBS 2008 in an environment with Windows 2000 DNS servers, you may receive the following error while running the EBS Preparation and Planning Wizards:
DnsConfig
A connection cannot be made to the WMI provider with a scope of \\Win2kDNS.contoso.local\Root\MicrosoftDNS and a path of MicrosoftDNS_Server. For more information about troubleshooting problems with WMI, see WMI Troubleshooting at the Microsoft Web site (http://go.microsoft.com/fwlink/?linkid=122665).
The Microsoft IT Environment Health Scanner gives a similar error:
DnsConfig
A connection cannot be made to the DNS WMI provider with a scope of \\sbs2000srv.contoso.local\Root\MicrosoftDNS and a path of MicrosoftDNS_Server. Ensure that a DNS WMI provider has been installed.
Cause
This occurs because Windows 2000 Server does not install DNS WMI Provider by default when the DNS Server Service is installed. The Preparation Wizard and IT Environment Health Scanner both use WMI extensively to query all the DNS servers in the domain. Therefore you need to install the DNS WMI provider from the site below on all Windows 2000 DNS servers mentioned by the tool (in the above example above there is only 1 Windows 2000 DNS server listed).
Installing the Provider
http://msdn.microsoft.com/en-us/library/ms682138(vs.85).aspx
Once the DNS WMI Provider has been successfully installed on the Windows 2000 DNS servers click on Scan again on the Preparation Wizard or IT Environment Health Scanner. The tool will restart the scan.
However, in a few cases we have seen that even after we install the DNS WMI Provider on the Windows 2000 machine the tool fails with the exact same error.To resolve this issue please reboot all the Windows 2000 DNS Servers on which the DNS WMI Provider was installed and then re-run the scan on the Preparation tool.
If the tool still fails again then one of the reasons could be due to WMI repository corruption on the Windows 2000 Servers. Please follow the link below to troubleshoot WMI.
http://msdn.microsoft.com/en-us/library/aa394603(VS.85).aspx
Do I need to keep the Windows Server 2000 DNS Server?
We see many environments in the sub-250 seat range that tend to be over-built in terms of DCs and DNS servers. Very few of these domains benefit from more than 2 DNS servers (that is to say, there will be little to no impact on login speed, Exchange performance, internet browsing, etc). If you have a domain where there are multiple Windows Server 2003 or greater DCs, consider decommissioning any Windows Server 2000 DNS servers if possible before upgrading.
[Today’s post comes to us courtesy of Mark Stanfill]
By default, TMG disallows WMI traffic as part of its security hardening. However, the Microsoft IT Environment Health Scanner (direct download) requires WMI to collect data for its analysis. To work around this limitation, you must temporarily create an exception to allow the Health Scanner to successfully complete. On a default run, you will see an error like the one below:
To prevent this error, you must explicitly configure TMG to allow WMI traffic from the computer where you are running the IT Environment Health Scanner. The steps below show us running the Health Scanner from the Messaging Server for demonstration purposes, but the same principles apply to running the tool from any server or workstation.
- Create an Access Rule in TMG
- Log on to the Management Server as an administrator and load the Forefront TMG Management console.
- Highlight the first rule in the Firewall Policy list. This will ensure that the new access rule is placed before any other rules that might interfere.
- Right-click Firewall Policy and select New and Access Rule…
- Follow the prompts in the New Access Rule Wizard, using the following settings (choose the defaults if not specified):
- Rule Action: Allow
- Protocols: All outbound traffic
- Access Rule Sources: Add the computer you are running the IT Environment Health Scanner from. Add a new computer object if needed.
- Access Rule Destinations: Choose Local Host from Networks.
- Right-click on the newly created rule and choose Configure RPC Protocol from the drop-down list.
- Deselect Enforce strict RPC compliance
- Click OK to save and exit
- Edit the TMG System Policy
- Right-click on Firewall Policy in the Forefront TMG Management console and choose Edit System Policy…
- Select Authentication Services from the list on the right and then select Active Directory.
- Deselect Enforce strict RPC compliance
- Select OK to save the changes
- Click Apply to save the changes to TMG. Wait until the configuration status under Monitoring shows that the changes have taken effect.
- Run IT Environment Health Scanner – Return to the server or workstation where you installed the Health Scanner and re-run the tool.
- Revert the Changes
- Return to the Management Server and disable or delete the access rule created in step 1 above.
- Re-enable strict RPC compliance on the Authentication Services\Active Directory system policy.
- Apply the changes.
