Endpoint Security Complete

 View Only

Upgrading Mobile Security Gateways for Symantec Mobile Security 7.2 

Sep 04, 2013 05:00 PM

The Story So Far...

This is the fourth in an informal series of illustrated articles about how admins (and end users) can best protect their mobile endpoints using Symantec Mobile Security 7.2. (This is a cool Enterprise product aimed at corporate networks, rather than a company that just has a few Androids or Windows Mobile devices that need protecting.) The three earlier articles:

  1. Illustrated Guide to Installing Symantec Mobile Security 7.2: how is the management server (Symantec Management Platform) of SMS 7.2 installed, and what does its interface look like? 
  2. Getting to Know the Symantec Mobile Security 7.2 Client: what does SMS 7.2 look like on an Android phone or tablet?  How to view its activities, launch an update, know when it is trying to alert you to danger.... 
  3. About Windows Mobile in Symantec Mobile Security 7.2: all about "Android’s ugly older brother."-  &: ) SMS 7.2 also protects Windows Mobile devices (phones, PDA's, various Point-Of-Sale equipment).  This article illustrates WM and how to administer them from the server console
     

By popular request, this fourth article deals with a cosmetic issue that many admins encounter: what to do about the "old" versions of the Mobile Security Gateway that appear in the SMP.

 

That's Great!  Erm... What's a Mobile Security Gateway? 

All Android devices communicate to their Symantec Management Platform (SMP) though a server known as a Mobile Security Gateway (MSG).  This MSG can be on the SMP server itself (one MSG is deployed there by default, when the management components of SMS 7.2 are installed) or your MSG can be on a separate server elsewhere in the organization.  Different groups of Androids can communicate through different MSG's.  Which one MSG a group of Androids will use is configured by policy (on the "Communications" tab, to be specific).

These MSG servers are often placed in the DMZ.  To illustrate, here's a diagram ripped off from page 105 of the Symantec™ Mobile Security 7.2 MR1 Implementation Guide:

msg_typical_implementation.png

This article has more information on what MSG's are and what they do:

Recommendations for Configuring a Healthy Mobile Security Gateway for Symantec Mobile Security 7.2
http://www.symantec.com/docs/TECH197866 
 

...and here's an example of what the MSG's look like, when displayed in the SMP's user interface.  In this example, there is one MSG on the SMP itself ("MICKSMS72") and one MSG in the DMZ ("EX2008EN"):

TECH197866_two_msgs.png

(Sharp-eyed readers will note that both MSG's make available for download an old version of the Android client- 7.2.0.145.  Definitely make sure that your MSG's are providing the latest and greatest- at the moment, that is SMS 7.2 MR1 hot fix 3.)

 

Hey! When I look at my MSG's, I see a scary message, "Verify Failed" or "Install Failed"

Don't panic. That's a common cosmetic issue on Windows servers that do not have the Altiris server's expected Short Date Format of YYYY-MM-DD.  This article explains all:

"Verify Failed" Messages Appear for the Mobile Security Gateway for Symantec Mobile Security 7.2
http://www.symantec.com/docs/TECH198622 
 

 

Whew!  That's Good.  But why are there two different Gateway Versions?  Did something go wrong when the SMP was upgraded? 

Nope.  When the SMP is upgraded by applying hot fixes, the version of the MSG is not automatically changed.  Here's an article with details of how the latest available release is applied to the SMP and Android clients. 

Upgrading Symantec Mobile Security 7.2
http://www.symantec.com/docs/TECH206224 
 

Though there are two different versions of the MSG (7.2.695.0 and 7.2.721.0), both work fine with any current release of SMP and the Android clients.  There's no compelling technical reason to upgrade the MSG on a functioning server.

 

If I really want to, can I get the newer MSG version deployed anyway?

Yes, but it will take a little work.  (This might be a substantial amount of work, if there are a large number of Android devices currently using that MSG.)  Here's what to do....

It's not possible to simply overwrite an existing MSG and progress it to a newer build.  In order to get a MSG up to the latest release, you must:

  1. Delete the old MSG
  2. Deploy a new MSG in its place

This is slightly complicated by the fact that the SMP will not allow a MSG to be deleted if any policies are configured to use it. So the actual steps are:

  1. Ensure they you have more than one MSG
  2. Clone your existing policy (if necessary) and change its configuration with regards to the MSG that will be used 
  3. Ensure that all Androids have received this new policy and that none are still communicating through the old MSG
  4. Delete the old MSG
  5. Deploy new MSG in its place
  6. Change the policy in use so that the Android clients communicate through their original, upgraded MSG

 

Can you walk me through that step-by-step? 

Sure.  &: )

1. Ensure they you have more than one MSG

Detailed instructions on how to create a second MSG can be found in:

Recommendations for Configuring a Healthy Mobile Security Gateway for Symantec Mobile Security 7.2
http://www.symantec.com/docs/TECH197866 
 

You might need to deploy a Symantec Management Agent ("Altiris agent") onto the second server first.  A server can't be set up an a MSG unless it has an agent that is communicating with the SMP.
 

2. Clone your existing policy (if necessary) and change its configuration with regards to the MSG that will be used

Just click "Add New Policy...."  In the window that opens, there will be a prompt "Enter a name for the new Mobile Security Policy then select an existing Mobile Security Policy to clone." 

clone_policy.png

The new policy will be created in no time.  Changing what gateway the Androids will communicate through is easy.  Just pick the desired MSG from the Policy's "Communications" tab where it says "Mobile Security Gateway that the device will communicate with."  In my example, I am creating a policy where all Androids communicate through the DMZ gateway "EX2008EN"..... 

changing_msg_in_policy.png

3. Ensure that all Androids have received this new policy and that none are still communicating through the old MSG

Make sure that there's no policy left which references the old MSG for communications, and then make all Androids check in.  "Update Device Protection" will do that.   

update_device_protection_many.png

In practice, it can take a while for all the Androids in a large organization to check in, apply their new policy settings, and begin communicating through their new MSG.  On the Mobile Security Gateway screen in the GUI, it is possible to see how many devices are connected through each MSG.  Ensure that there are no Androids still connecting through the MSG that is to be deleted- they will need to re-enroll later, if so! 

4. Delete the old MSG.

Highlight the old MSG and click the red X to delete it.  There will be a warning message if you have not completed Step 3, above!

cannot_delete_while_policies.png

If there are no policies left which call for this MSG, then the warning message will warn you if there are any Androids still using this MSG. 

deleting_msg_warning.png

Even if there are Androids that will be affected, it will be possible to click OK to proceed and delete the MSG.  Check the Symantec Management Agent on that server to make sure that the Uninstall Gateway Task has completed.

 

5.  Deploy new MSG in its place

Just click on New...

deleted_msg.png
 

Pick the server where the MSG should go by clicking "select a server" and navigating....

can_then_roll_out_a_new_msg.png

Click "OK" - the "new" MSG will soon appear in the GUI!  At first it will display with a Gateway version of 7.2.0.0 and a status of "Waiting for rollout."  This is normal.  Open the Symantec Management Agent to make sure that the Update Mobile Security Gateway task has completed successfully:

successful_msg_rollout.png

Within a few minutes, the MSG's will both have the latest version in the GUI:

successful_in_gui.png

6. Change the policy in use so that the Android clients communicate through their original, upgraded MSG
 

Change the MSG to use on the policy "Communications" tab, as illustrated above.  If a second MSG was created for temporary use while the older one was being "upgraded," verify that no Androids are still using it and then safely delete it.

That's all!  The Mobile Security Gateway has been successfully upgraded.     

 

In Conclusion.... 

Many thanks for reading!

As stated above, this procedure really should not be necessary if all Androids are communicating successfully through their existing MSG's.  Please do leave comments below to provide feedback, and please do highlight any tips that you have discovered that other admins may find useful. 

Please also do comment with any requests for future articles in this series!  This illustrated guide was create due to popular demand, so perhaps your request will be, too.

 

 

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Sep 07, 2013 05:21 AM

The article was very useful to me. Thanks.

Related Entries and Links

No Related Resource entered.