In the centralized topology, the implementation of an enterprise consists of multiple domains where all Microsoft Office Communicator Server 2007 components are hosted at the central site. Users access Microsoft Communicator Mobile 2007 services across the LAN or WAN from local or regional company sites. The centralized topology is preferred by organizations that want to minimize the IT footprint and rely on relatively few groups in the organization to manage and monitor the web or portal environment. For more information on planning and deploying Microsoft Office Communicator Mobile 2007, see to the “Microsoft Office Communicator Mobile (2007 Release): Planning and Deployment Guide” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116561.

MDM establishes an Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel on the Internet between a domain-joined Windows Mobile 6.1 device and the company perimeter network. After a mobile device is connected to the Mobile VPN, the MDM Gateway Server role provides an Internet Protocol (IP) address from a VPN IP address pool for mobile devices. This allows mobile users to connect to Office Communications Server 2007 servers that are hosted in the company network at the central site.

Network Routing Considerations

You should consider the network routing implications when deploying Communicator Mobile clients to mobile devices. The Communicator Mobile 2007 client can connect to the Office Communications Server 2007 Edge Servers in the perimeter network or, after establishing the VPN tunnel to the MDM Gateway Servers, can connect directly to the Office Communications Server 2007 pools in the company network. The Communicator Mobile client must be able to establish Session Initiation Protocol (SIP) communications to the Office Communications Server Roles.

The Communicator Mobile client uses Transport Layer Security (TLS) over TCP port 443 when directing network communications to the Office Communications Server Edge Servers.

The Communicator Mobile client can connect to the server using HTTPS/TLS or TCP. The preferred mode of connection is TLS, and it is required when the client connects to the server while using an external Wi-Fi or mobile wireless network. It uses TLS over TCP port 5061 when directing SIP communications directly to the Office Communications Server server pools on the company network.

To integrate MDM with a centralized Office Communications Server 2007 enterprise topology, you must configure IP routing between the MDM Gateway Servers and the Office Communications Server 2007 edge servers or Office Communications Server server pools to enable Communicator Mobile client access from the Internet to the internal company network. Managed Windows Mobile 6.1 devices will use the IPsec protocol between the mobile VPN client and the MDM Gateway Servers to enhance the security of the TLS session to the edge servers or server pools. You may need to open additional ports on the external and internal firewalls to support services such as file transfer and audio/visual services, if not already supported by the Office Communications Server Edge servers. For more information on the full range of ports required by the various Office Communications Server 2007 Server and client roles, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121384. For additional information about the configuration of firewalls in front of or behind the MDM Gateway servers, see to the MDM Planning Guide at and the MDM and Configuring External and Internal Firewalls in Mobile Device Manager at these Microsoft Web sites: http://go.microsoft.com/fwlink/?LinkID=116398 and http://go.microsoft.com/fwlink/?LinkID=120386.

Note:
The Communicator Mobile client does not use SRV record to locate Office Communications Server Access Edge servers.

For external access to succeed, Communicator Mobile must use TLS transport. By default, it uses port 5061, but it can use other ports, such as port 443, for external access. You must configure Communicator Mobile clients to include the port information in the server address. The correct format is <fully qualified domain name address>:<port number>. For example, you should configure the client to use sip.contoso.com:443 as the external server address if the Access Edge Server in Office Communications Server 2007 is configured to use the default remote client access settings. For more information about this port configuration on the Edge Server, see “Microsoft Office Communications Server 2007 Edge Server Deployment Guide” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121386.

For more information about Office Communications Server 2007 planning to determine if you need Office Communications Server Edge Servers, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121387.

The following illustration shows a managed device with the Communicator Mobile client establishing a VPN tunnel to the MDM Gateway Servers, then communicating to the Office Communications Server 2007 Edge Servers in the perimeter network. A solid line shows this communication. The dashed line shows how managed devices communicate directly to the Office Communications Server 2007 Server pool after terminating the IPsec VPN connection at the MDM Gateway Servers.

The decentralized topology supports larger enterprises with multiple domains, multiple locations, that have a decentralized management of Microsoft Office Communications Server 2007. This topology differs from an MDM infrastructure designed for a central Microsoft Office Communications Server 2007 topology in that the design places emphasis on establishing the shortest, and hopefully quickest, route to the Microsoft Office Communications Server 2007 server infrastructure. Under most scenarios, we recommend that you direct traffic to the nearest Microsoft Office Communications Server 2007 edge servers to let the default proxy mechanisms operate as designed. In the scenario where Microsoft Office Communications Server 2007 infrastructure is dispersed between geographic sites, you must provide a localized network route to the nearest well-connected company perimeter network.

The following illustration shows an example of a decentralized deployment of the Communicator Mobile client. The solid lines show the potential network communications based client communications to Office Communications Server Edge Servers. The dashed lines show the communications directly to the Office Communications Server server pools.

Network Routing Considerations

Similar to the centralized topology, you must consider network routing for mobile device IP traffic flow between the MDM Gateway and Microsoft Office Communications Server 2007 edge server in the perimeter network such that communication from mobile device to Microsoft Office Communications Server 2007 SIP traverses physical network boundaries and locations. Office Communications Server 2007 pools can span sites, or each site can have its own Office Communications Server 2007 pool. To allow Communicator Mobile clients to connect to the appropriate Office Communications Server 2007 pool as defined in Active Directory, you must understand the network routes that roaming requires.

Note:

You must deploy Office Communications Server Access Edge Servers in a single site. In a decentralized MDM deployment, we recommend that you provide network connectivity directly to the Office Communications Server 2007 pools to minimize the number of jumps in the network route. If a managed device connects to an MDM Gateway Server in a secondary site, the Communicator Mobile traffic can traverse numerous network segments to route to the Office Communications Server 2007 Access Edge Servers in the central site’s perimeter network.

The decentralized Office Communications Server 2007 deployment with branch office scenario is similar to the decentralized scenario but requires support for remote locations. The branch office scenario supports a small office or retail site that has less than 100 workstations and little or no server infrastructure. Typically, branch offices have no web server components or MDM server roles deployed locally. Therefore, the branch office scenario is similar to the centralized topology where mobile devices use the operator network to establish the shortest path to an MDM Gateway Server and route Communicator Mobile network traffic to the Office Communications Server 2007 server pool, or connects directly to the Microsoft Office Communications Server 2007 edge server in the perimeter network at the central site.

The Communicator Mobile client requires additional configuration to successfully connect to the Office Communications Server 2007 infrastructure and provide presence information on the mobile device. For information about how to use an .inf file to configure a Communicator Mobile client by using ActiveSync, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121406.

When deploying the Communicator Mobile client with MDM Software Distribution, you may need to provide Communicator Mobile client registry settings. In this way, you can reduce the amount of manual configuration experienced by the users. Users may still need to manually configure their sign-in name, username (in the form of <domain>\<username>), and password, but you can configure the registry with other information before you distribute packages.

Note:
Registry values may be overwritten during program installation. You can apply group policy to persist registry settings, but the registry values may be temporarily replaced with default values immediately after program installation. When group policy is refreshed, the values are replaced by those specified by group policy.

The default policy calculation is 8 hours. However, you can change this value by using the Set-MobilePolicyServiceConfig cmdlet in the MDM Command Shell on the MDM Device Management Server. You can also force policy refresh on an individual device basis by using the Update-MobilePolicyCalculation cmdlet from the MDM Device Management Server.

To configure the registry, you can change the following values in HKCU\Software\Microsoft\Communicator\System Settings on the device:

Server

The server address to display in the External server name box in Communicator Mobile Options.

ServerInternal

The server address to display in the Internal server name box in Communicator Mobile Options.

RememberPassword

If set to 1, the Remember my password check box in Communicator Mobile Options is selected. If set to 0, the check box is cleared.

DisableCertCheck

If set to 1, certificate revocation list (CRL) checking is disabled for the Communicator Mobile client. If set to 0, CRL checking is enabled.

AutoLogon

If set to 1, the Automatically Sign in check box in Communicator Mobile options is selected. If set to 0, the check box is cleared. This setting is applied only if RememberPassword is set to 1.

You should manage the registry values required by the Communicator Mobile client through Group Policy. To do this, you would create a custom Group Policy Administration template (.adm) to manage the Communicator Mobile specific registry settings. For more information, see “Writing Custom ADM Files for System Policy Editor” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=109295.

The following example is a custom .adm template that you can use to define registry settings. You can use this example to create a new Administrative Template for managing registry settings on mobile clients. For example, you can use this template to include a group of policies for defining the server names for the internal and external Office Communications Servers.

;======================================================================
; Custom Registry Administrative Template File
; _version="1.0"
;======================================================================
CLASS MACHINE
CATEGORY "Custom Registry Settings"
   CATEGORY "Communicator Mobile"
   POLICY "Communicator Mobile" 
      EXPLAIN !!ExplainCoMo
      KEYNAME "SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKCU\Software\Microsoft\Communicator\System Settings"
      PART "Server"
         EDITTEXT
         VALUENAME "Server"
      END PART
      PART "ServerInternal"
         EDITTEXT
         VALUENAME "ServerInternal"
      END PART
   END POLICY 
   End CATEGORY 
END CATEGORY 
[STRINGS]

For ExplainCoMo, the Server value indicates the public FQDN of the OCS services. The ServerInternal value indicates the internal FQDN of the services. For example, sip.contoso.com. For more information about configuring registry values for Communicator Mobile, see http://go.microsoft.com/fwlink/?LinkID=121406.

You can use Group Policy to set these values, and then use the existence of these values as a dependency to install the Communicator Mobile client package. The dependency is defined during package creation. For more information, see “Creating a New Package” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=11241.

Note:
You can use third-party tools to modify .cab files to include the required registry settings and preconfigure portions of the Communicator Mobile client.

1. Configure Active Directory Group Policies to deploy the required root certificates to the Software Publisher Certificate (SPC) and Unprivileged Execution Trust Authorities stores on the mobile devices.
   The SPC store governs cab installation on a Windows Mobile Device. The Unprivileged Execution Trust Authorities store is used by Windows Mobile security to control code execution. If an executable can be chained up to a certificate in this store, it is considered signed and is assigned a trust level based on the device security policies. For more information about this process, see “Importing Certification Authority (CA) Certificates” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=11241.
   
2. Create a Personal Security Certificate (PFX) and code signing template for signing the Microsoft Office Communicator Mobile 2007 cab files. For more information, see “Creating the Personal Information Exchange (PFX) Certificate” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=112415.
   

   Note:
   It is advantageous to use the same certificate chain to create the code signing clients as that used to issue the MDM client certificates. The certificate chain is automatically deployed to the MDM mobile client Root Certificate store during device enrollment. You must still install the Root Certificate in the SPC and Unprivileged Execution Trust store.

3. Export the PFX file generated in the previous step, and then copy it to the trusted publishers and enterprise root certificate stores on the machine that you will use to sign the Microsoft Office Communicator Mobile 2007 cab files.
   
4. Download Microsoft Office Communicator Mobile from Microsoft Downloads, and then run the .msi to extract the .cab files for mobile clients. Microsoft Downloads is at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121409.
   

   Note:
   There are two .cab files; one for the Windows Mobile Professional (Communicator.PPC.cab) and one for Windows Mobile Standard (Communicator.SP.cab). You must package each .cab separately for the appropriate device.

5. Using CabSignTool, sign the Microsoft Office Communicator Mobile 2007 cab files. For more information, see “Scripted Signing of .Cab files using the CabSignTool Utility” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=11241.
   

   Note:
   The CabSignTool is available as a download at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116086. It includes the three files required to successfully sign .cab files for distribution. The three files include: Cabsigntool.exe; CAPICOM.dll (version 2.1.0.1); and Signtool.exe.

6. Install the Code Signing Certificate to the Trusted Root Certification Authorities store and the Trusted Publishers store for the machine that will be used to sign .cab files. If you run MDM Software Distribution Console on a separate computer, follow these steps on both the computer that has the console and the computer that has the WSUS server. For more information, see “Publishing .Cab Files” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=11241.
   

1. In the MDM Software Distribution Console, create a Software Distribution Device Group for targeting the Microsoft Office Communicator Mobile 2007 cab files to mobile devices. To organize a set of mobile devices into a managed collection, you must create a device group into which you can add the mobile device accounts.
   
2. Configure Software Distribution to either use client-side or server-side targeting.
   By default, MDM Software Distribution uses server-side targeting, meaning the MDM Software Distribution Console is used to manage device group membership. Client side targeting uses either group policy or registry values on the mobile devices to associate devices to the groups defined in the console. To enable client-side targeting, you would change the Targeting Options on the Devices node in the console and then configure client side targeting with group policy. For more information, see MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=112415.
   
3. Use the Create Package Wizard to create a .cab package for deployment to mobile devices.
   This tool lets an administrator create a software package, choose the devices that will receive the package, set specific dependencies, and control the installation. After a software package is created in the MDM Software Distribution Console, the package must be approved by IT administrators for deployment to managed devices. For more information about creating packages for MDM software distribution, see this “Creating a New Package” in MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=112415.
   

To determine if the application installed on the mobile devices that had the software distribution policy applied, select Start, and then choose Programs. If the application installed successfully, Microsoft Office Communicator Mobile 2007 application will display under Programs.

Like many applications designed to support Internet based clients, you should make sure that there is end-to-end functionality from the company network, through the perimeter, and ultimately to the mobile device client. Once installed and configured with the appropriate server sources, credentials, and password, the Communicator Mobile client should successfully sign in. The presence of users online should then be visible and the presence of users logged in should change between online, away, busy, and so forth.

Package Creation

Group Policy

Software Distribution

If software distribution fails to publish, the most likely cause is that the required certificates are not present in the certificate stores on the publishing machine and/or the MDM Device Management Server.

If software distribution fails to install software on the mobile device, the most likely cause is that the software distribution publishing certificates are not in the correct certificate stores on the device. The following list shows ways that you can resolve this issue:

• Run the powershell cmdlet UpdateMobilePolicyCalculation –DEVICENAME on the MDM Device Management Server, where DEVICENAME is the name of the device that is failing
  
• Before targeting software for installation, use the MDM ConnectNow tool to force an OMA-DM session with the MDM Device Management Server. This ensures that the software publishing certificates have been pushed to the device before MDM Software Distribution offers software to the device.
  

Overall, if software distribution fails for any reason, Mobile Device Manager retries the distribution in seven days by default. The seven day count starts when the device notifies the MDM Device Management Server of the installation failure. You can change the default retry interval by running a MDM Powershell cmdlet Set-SoftwareDistributionConfig –ReofferPeriodDays, where 0 is a value to reoffer the software package immediately at the next OMA-DM session.

Note:
We recommend that you only set the Set-SoftwareDistributionConfig value to 0 in test MDM environments.

The following illustration shows the simple installation flow for new devices in MDM:

The following illustration shows the simple MDM software distribution package flow for software distribution failures.

The following illustration shows the different package reporting conditions in the MDM Software Distribution Console. This information helps you understand the meaning of software package status in MDM.

You can download the Microsoft Office Communicator Mobile (2007 Release): Troubleshooting Guide from this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=121478.

The ADConfig tool, ADConfig.exe, is a configuration tool that you must use to configure Active Directory for MDM. ADConfig lets you do the following:

• Create the Active Directory Universal Security Groups and containers for MDM
  
• Add the service connection points (SCP) for MDM
  
• Create the Mobile Device Templates in the enterprise certification authority
  

For more information about ADConfig, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116264.

MDM Console

Group Policy Extensions

MDM Software Distribution Management Console

MDM Shell

MDM populates Application, System, and Security events in the Event Log. Use Event Viewer to obtain information and details when a specific issue occurs.

The SCMDMsetup.log file contains information that is collected from MDM component .msi installation logs. However, it does not contain verbose installer data, and does not report return values for custom actions. You can get more comprehensive information, including return values, from the .msi logs for each MDM component installation.

Windows Installer version 3.1 .msi logs provide details about the installation of server roles and components in the DM.log, Enrollment.log, and AdminTools.log.

The Verbose Windows Installer Logging (WILogUtl.exe) produces a verbose log file that you can use to find the source of an error.

An MDM Event Viewer node is created when MDM system components install. This provides information on application and installation errors.

The VPNGateway.log file is created in the Temp directory during the MDM Gateway Server Setup process.

Creating logs by using MDM Shell cmdlets to enable WPP produces log files that you can analyze for debugging and troubleshooting issues.

Use the Services MMC snap-in to start, stop, and verify that certain services are running.

Use the MDM Console for device status information or package installations.

Use MDM Shell to run cmdlets that retrieve data or set configurations.

Use ADSIEdit.msc to view and change Active Directory. This tool is a low-level editor for Active Directory that provides a graphical user interface (GUI). It is useful to add, delete, and move objects in a directory service.

Use the Report Viewer tool to collect data from Active Directory and the MDM databases. MDM Reporting Services uploads data to a reporting database for comprehensive and detailed reporting capabilities.

Use Logman.exe when Windows Event Logs are insufficient for troubleshooting a problem. You can start WPP tracing for the VPN server to obtain detailed trace logs.

The MDM 2008 Resource Kit – Server Tools is available as a download at http://go.microsoft.com/fwlink/?LinkID=116086. It includes the following:

MDM Bulk Pre-Enrollment Tool

MDM Application Hash Code Tool

MDM Cleanup Tool

MDM Device Enrollment Cleanup Tool

MDM Certificate Tool

The MDM Resource Kit Best Practice Analyzer (BPA) helps you to analyze the prerequisites for MDM setup and deployment. Because each MDM server component has different prerequisites, the tool helps you to plan and build a successful deployment environment by assessing each server's readiness for MDM before you run MDM Setup.

In addition to analyzing the readiness of each server, BPA Tool helps you to verify the firewall configuration that MDM requires between servers running MDM Device Management Server and servers running MDM Gateway Server. After you deploy MDM, you can then run a post-deployment scan to help make sure your installation works properly and follows MDM best practices.

You can download the BPA tool at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116253.

You can download the MDM Resource Kit Client Tools at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116254.

MDM Connect Now Tool

VPN Diagnostics Tool