[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.
[Today’s post comes to us courtesy of Mark Stanfill]
We get a fair number of queries about CAL enforcement in EBS support, so I’d like to try to clear up some of the common questions that our partners have. Because EBS enforces client licensing in a fairly strict manner, it is important to understand the repercussions of being out of compliance in order to ensure that your clients are able to successfully connect to the network.
How to Properly License Clients
Assigning CALs to users is a simple process:
- Activate the server. Do this from Control Panel\System as you would for any Windows Server.
- Install the CAL Packs using the EBS Administration Console.
- Open the EBS Administration Console and select the Licenses tab.
- Select Install CAL packs from the License Management Tasks.
- Follow the prompts, and enter the CAL Pack product keys when prompted
- Assign the CALs to users or devices using the EBS Administration Console.
- For existing users, open the EBS Administration Console and select the Users and Groups tab.
- Select the user and double-click or choose Change user account properties.
- Select the CAL tab and assign the appropriate CAL (Standard or Enterprise).
- Click OK to exit.
CALs must be assigned to users. Installation does not automatically assign a CAL to any users. This task is covered in the Guided Configuration and Migration Tasks during setup as well.
Enforcement Model
EBS does not enforce any licensing restrictions for the first 30 days after Management Server is installed. You can verify that you are in this state by looking in Event Viewer on Management Server under Applications and Service Logs\Microsoft\Windows\Server Infrastructure Licensing\Operational. The presence of Event 39 in this log indicates that the server is in the initial grace period:
After 30 days, enforcement will begin. Any client that is not assigned a CAL at this point will only be authorized to log in to servers or to workstations that have been assigned CALs. The licensing service enforces this restriction by modifying the user’s Logon Workstation’s setting in AD. Any changes made to this key will automatically be reverted by the licensing service.
If a CAL has not been assigned to a user, they will be presented with the following error when attempting to log on to their workstation:
Your account is configured to prevent you from using this computer. Please try another computer.
User CALs vs Device CALs
Previous licensing models had the concept of user CALs versus device CALs. In EBS 2008, all CALs are “Universal CALs” and may be assigned to either a user or a computer as needed.
When you assign a User CALs to a specific individual, that person can use any PC or network device to access a Windows Essential Business Server 2008 server or other Windows server in the domain. When you assign a Device CAL to a specific device, then any number of individuals (but only one at a time) can use that device to access a Windows Essential Business Server 2008 server or other Windows server.
In most cases, assigning CALs to users is preferred. Assigning CALs to devices typically is used in very limited scenarios:
· Shared machines between shift workers
· Kiosk machines
· Machines shared between workers who don’t require concurrent access (for example, point of sale devices, computers used to check email in a warehouse, or computers only used to do a specialized function, such as scanning or machine automation)
Automating Assigning CALs
The BulkAssignCALs.ps1 PowerShell script will attempt to assign installed CALs to users in the domain. It is important to audit the accounts afterwards to make sure that test accounts, users who have left the company, etc. are not consuming CALs. This script is available here.
To run this script, do the following:
- On the Management Server, right-click the icon for Windows PowerShell and choose “Run as administrator”
- Save the file locally to disk, right-click on it, choose properties, and click on the Unblock button
- In the PowerShell command prompt, execute the script by navigating to where you saved the file and typing .\bulkassignCALs.ps1 standard (for standard CALs; substitute premium as appropriate)
- Open the EBS Administration Console, navigate to the Licenses tab, select User Licenses, and review the results. Ensure that users have the correct edition.
[Today’s post comes to us courtesy of Mark Stanfill and Chris Puckett]
Updated 10/12/2009 – new version of script linked.
You may see installation failures of Microsoft .NET Framework 3.5 Service Pack 1 (KB951847) on the 3 EBS Standard Edition Servers. Clients and other servers are not affected. The behavior is that the update will fail to install and continually be offered each time you check for new updates.
The following event will be logged:
Log Name: Application
Source: MsiInstaller
Date: 5/6/2009 3:17:22 PM
Event ID: 11325
Task Category: None
Level: Error
Keywords: Classic
User: CONTOSO\Administrator
Computer: msg.contoso.local
Description:
Product: Microsoft .NET Framework 3.5 -- Error 1325.'Microsoft.NET' is not a valid short file name.
To correct this, run the following steps on all 3 EBS Servers:
1. Log on to the server and copy this script to your server.
2. Either copy and paste the contents in to a new file created locally on the server or else unblock the content. To unblock content, right-click on the file in Explorer, choose Properties, and choose Unblock on the General tab.
Click apply and OK.
3. Open an elevated command prompt and execute the script:
Note: You may see a few “Property ___ does not exist” errors. These are innocuous and can be ignored.
4. If prompted, copy WFServicesReg.exe from another system to the C:\Windows\Microsoft.NET\Framework\v3.5 and C:\Windows\Microsoft.NET\Framework64\v3.5 folders. The versions of WFServicesReg.exe in each folder are different. The current version is 3.4.5940.0 for both files. The \Framework folder version is 178 KB, while the \Framework64 version is 267 KB.
5. Run the hotfix.
Others have blogged solutions that will also work, but take much longer than the script to run.
[Today’s post comes to us courtesy of David Fabritius]
Midsize businesses interested in upgrading to Exchange Server 2007 should consider Windows Essential Business Server (EBS) 2008. EBS 2008 is an integrated software suite that is designed and priced for midsize businesses and includes Exchange Server 2007 as one of its core components. When you deploy Windows Essential Business Server 2008, in addition to getting all the value of Exchange Server 2007, you will also see added benefits from the other integrated components such as Microsoft System Center Essentials and Microsoft Forefront Security, as well as value-add features specific to EBS 2008, including a unified Administration Console and the Remote Web Workplace. And for those companies looking to support their line-of-business applications, EBS 2008 Premium includes SQL Server 2008. To learn more, [register to] watch the webcast presentation here.
1. Exchange Server 2007 is easier to deploy as part of the EBS 2008 solution.
Because the installation of Exchange Server is integrated into the overall setup experience of EBS 2008, it is easier to deploy and configure. Messaging infrastructure design considerations and best practices configuration settings appropriate for the needs of midsize business environments have been fully implemented as part of the guided setup process. This reduces the time and effort needed to get up and running with Exchange Server 2007, and well as providing a high degree of manageability, reliability, security, and confidence in having a solid IT infrastructure. Important productivity features of Exchange such as Outlook Anywhere and Outlook Web Access are fully configured and ready to use without any additional configuration steps.
2. EBS 2008 saves you money by lowering the total cost of ownership of managing and operating Exchange Server 2007.
EBS 2008 provides a unified Administration Console which enables midsize businesses to proactively manage their entire IT environment, including the Exchange Server. By leveraging the monitoring and alerting capabilities of System Center Essentials, the IT staff can proactively manage the environment instead of constantly reacting to issues that may impact business productivity. Sumeeth Evans, Director of IT for Collegiate Housing Services, has experienced tremendous improvements: “Our administrative workload is one-tenth what it was before.… This is the largest step forward, in terms of our ability to focus on real business needs that we have ever seen."
3. EBS 2008 reduces the complexity of securing your Exchange Server 2007 environment.
EBS 2008 starts midsize business off on the right foot by including over 300 pages of best practices and 15 security settings into the setup process, providing a solution that is secure by design. EBS 2008 also includes Forefront Security for Exchange Server which integrates multiple scan engines from industry-leading security firms into a comprehensive, layered solution, helping businesses protect their Microsoft Exchange Server messaging environments from viruses, worms, spam, and inappropriate content. In addition, EBS 2008 includes Forefront Threat Management Gateway (TMG) Medium Business Edition as part of the infrastructure solution which provides enterprise-class firewall capabilities and Unified Threat Management (UTM) protection by tightly integrating with the components and applications of the whole IT infrastructure.
For more information on upgrading Exchange as part of the EBS solution, or for more information on Windows Essential Business Server please visit http://www.microsoft.com/ebs/en/us/whyupgrade.aspx.
[Today’s post comes to us courtesy of Becky Lymberis]
For many midsize businesses, a day in the IT department is often about putting out fires and running to users’ desktops to troubleshoot issues. Problems like this are not uncommon; with fewer resources than their enterprise counterparts, managing and keeping an updated IT department is extremely challenging. As the business needs evolve, servers tend to proliferate and suddenly the business is running on multiple versions, all with different tools to manage a complex environment.
We wanted help midsize businesses get a great experience and high ROI from our software so we built Windows Essential Business Server 2008 (EBS), an all in one server suite that consolidates the core infrastructure into a more streamlined environment for greater manageability, improved security, and more predictability so IT can be more productive and less reactive.
If the above is a familiar scenario for you or your customer and you’re considering a server upgrade for any reason, consider this; Essential Business Server 2008 will give you all of the features and value of the upgraded server whether it’s Exchange Server or Windows Server, but you’ll also have an environment that is simpler to manage. There are features unique to EBS 2008 such as the unified management console to view and manage the IT environment, integrated management software with System Center Essentials, out of the box remote access with Remote Web Workplace, and added security with Forefront Threat Management Gateway and Forefront Security for Exchange. It’s all set up to best practices (over 300+ pages – think of the time saved referencing those) - to reduce risk and increase predictability.
From a business decision maker’s perspective, it’s all upside because IT can really optimize operations to reduce costs, enable remote workers with the secure remote access capabilities of Remote Web Workplace, and overall be more secure with latest software and tools to help IT know the health of their environment at all times. The outcome is improved uptime of critical applications.
If you’re interested in finding out more you can visit our product website, or you can try EBS 2008 for free. We’d love to hear from you! Please join the EBS community on Facebook or e-mail us with your pre-sales questions to askebs@microsoft.com.
