Huntland Services Ltd

Tel: +44 (0)1392-490518
Fax: +44 (0)1392-428003
Enquiries@huntland.co.uk

Digest of Mobile Client Features and Functions in SMS Topaz

 Based on Microsoft Webcast 8th Jan 2002

Management Points
MP's only exist in Primary Sites and are available only for the use of Mobile Clients.   Standard clients continue to use CAPs.  Normally there is 1 per Primary Site,  the default MP, but for very large Mobile Client populations multiple MPs may be arranged to appear as one using load balancing.   Requires IIS 5.x which includes BITS.  Requires MSMQ message handling service.    Requires direct access to the SMS SQL Database (or a replica) to fetch policy data (SMS client configuration information) and  Distribution Points when requested by the client.  Communication with clients uses MSMQ for messages of less than 50kb and BITS for the larger ones.  BITS is also used for downloading policies using http Head (sic) and Get exchange. (See Digest of New Features & Functions of SMS Topaz or Ms Webcast 6th Sept 2001)

MP runs as a service called SMS Agent Host (ccmExec.exe) in winnt\system32\CCM using approx 1.25MB disk space and 12MB ram.  All components run as threads of this service (c.f.  smsExec.exe).  It creates an SMS inbox directory structure as in SMS\MP\Outboxes for discovery, inventory and status messages from Mobile Clients.  However this is different from traditional inbox management because each ccmExec component receives an xml message from the client sent using BITS or MSMQ, and is responsible for translating this into the correct format for subsequent transmission to the Site server.    BITS uses two IIS virtual folders CCM\incoming and CCM\outgoing.  The threads running under the SMS Host Agent on a Management Point are:

•  Inventory Manager (MP_Inventory_Manager)
  Processes incoming XML hinv, sinv and ddr  messages and translates them into the appropriate format , nhm, sic and ddr respectively, in preparation for dispatch to the site server.
•  Policy Manager
  Responds to client requests to fetch policy data from SQL Server.
•  Control Manager 
  Makes sure the Management Point is published in Active Directory and as a backup mechanism in WINS also. 
•  File Dispatch Manager
  Responsible for sending processed files to the site server (c.f. Inbox Mgr Asst on a CAP)
•  Location Manager
  Finds and returns best Distribution Point for client by examining list in SQL based on current subnet of client.
•  Status Manager
  Processes incoming xml status messages and translates into appropriate format for dispatch to Site Server.

MPs are configured through a new tab in Site System properties where an administrator can also select  whether to use the original database or a relocated replica.  Best practice is to install IIS and MSMQ first followed by SMS Management Point because SMS does not report IIS and/or MSMQ errors.

Distribution Points
The same as standard SMS but must be enabled for BITS to support mobile clients.  This is an extra checkbox in the Site System properties, distribution point tab dialog box.

 Mobile Client Architecture
Topaz has no logon (login script) based installation or discovery mechanisms.  Installation is based on a MSI file using one of the following four methods:

1. Software Distribution
   To an SMS 2.0 client or Topaz Standard client (approx 3.75 MB) using normal distribution advertisement.
2. Group Policy/Intellimirror
   Uses Win2k/XP/.Net assigned or published advertisements to start msi file install.
3. Preload in O/S image
   The msi file can be run manually on a system which can then be disk imaged for rapid deployment.  Topaz uses three criteria to uniquely identify a system: Windows Authentication code, SMBIOS serial number and computer SID.  Using these it will auto-generate a new SMSuid to avoid duplicated machines created by disk imaging.
4. Manual
   The administrator runs CLIENT.MSI

Once the Mobile Client is installed it blocks any attempt to install the Standard SMS client.  The Mobile Client uses the same SMS Host Agent service (CCMExec.exe) as the MP.  This is  installed in winnt\system32\CCM by default although it is configurable using a TARGETDIR switch on the msiexec command line.  It runs under the local system account using  a  footprint of 4MB disk space and a base memory of approx 10 MB rising to 12 MB with inventory, Soft Distrib and Remote Control activated.  Notice that all client functions are always installed but only activated under admin control via the policy.  The threads running under the SMS Host Agent on a client are:

• CCM Framework
• CCM Policy Agent
• CCM Status Agent
• SMS Shared Components
• SMS Remote Client Core Components
• SMS Inventory Agent
• SMS Software Distribution Agent
• SMS Remote Control Agent

Mobile Client Assignment

1. Manual assignment,  either at or after installation, is performed by simply providing a site code.  Notice it is not site boundary dependent.  This is the whole point of mobile clients.  
2. Auto-discovery assignment to the local site can only be done after installation and is performed by an SMS process. 

Assignment is required so a client can obtain a valid policy.  The client discovers the identity of its Management Point from Active Directory and sends a request for a policy (Mobile Client can function without AD using WINS instead to locate the MP).  The MP returns the policy in xml format. The client parses the xml file and updates its own persistent store in WMI based on the version numbers of the items. i.e. newer replaces old.

Mobile Client Functionality
The inventory agent performs hinv, sinv and discovery.  Hinv and sinv as as per SMS 2.0 with the data returned to the MP in an xml message.  The sms_def.mof file has the same role but is downloaded from the MP as an xml message.  ID and NOID  MIFs are still supported.  

The client's DDR is created according to the Heartbeat schedule and is an xml message containing the standard ddr fields plus a new one for the Active Directory Site name.     

Soft Distrib is the same as for a standard client except BITS enabled.  BITS allows use of a client side cache (500MB by default) for download and execute.  New advertisement settings allow  administrators to decide the install behaviour  if  the DP is local (download & execute or run from DP) or remote (do not run, download & execute, run from remote DP).

Roaming
Special Roaming Site boundaries (new tab in Site Server properties) can now be defined in terms of subnets (as before), Active Directory Site name or ranges of IP addresses.  The latter especially for RAS clients being allocated dynamic addresses from a known pool.  By comparing the clients properties with the roaming site boundaries a client can which site is local.   The managing site (the originally assigned site) doesn't relinquish responsibility for the client when it roams.  The client is never de-installed or overwritten when it visits another site (c.f SMS 2.0).  There are two types of roaming:

1. Regional roaming
   The client is at a site within its native hierarchy and is below its assigned site.   All sites that are below the assigned site can be furnished with information for the client (advertisements, software).  The client attempts to use its assigned site MP to obtain its policy via BITS.  It uses the local MP to learn about local BITS enabled Distribution Points.    It learns the identity of the local MP by querying Active Directory or WINS if AD is not available.   If no local MP can be found it uses the assigned site's MP.  Clients can use DPs in a secondary site even though there is no local MP.
2. Global roaming
   The client is at site in a foreign hierarchy or a site in the native hierarchy that is above the assigned site.  The new site has no information about the client which therefore treated as new.  The client must use the local MP and distribution Points.  Global roaming is possible if SMS Active Directory extensions have been installed.       If a client fails to find an MP there are no useful error or status messages generated.

Mobile Client vs Standard Client
Mobile Client is recommended because smaller, faster, uses local system account and an all mobile client site does not need traditional CAP servers. But a Mobile Client has no Topaz Soft Metering, must be managed through a Primary Site, and is only available for Win2k or above.  

Miscellaneous

• Still cannot schedule execution time for application install independent of advertisement. e.g. advert revealed at 01:00 hrs, install starts at 02:00.  Being considered.
• Topaz, like SMS 2.0, has no support for clustering
• No PDA type support but maybe in subsequent release.
• Remote Control same as SMS 2.0 but some performance enhancements