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:
- 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?
- 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....
- 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:
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"):
(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:
- Delete the old MSG
- 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:
- Ensure they you have more than one MSG
- Clone your existing policy (if necessary) and change its configuration with regards to the MSG that will be used
- Ensure that all Androids have received this new policy and that none are still communicating through the old MSG
- Delete the old MSG
- Deploy new MSG in its place
- 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."
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".....
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.
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!
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.
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...
Pick the server where the MSG should go by clicking "select a server" and navigating....
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:
Within a few minutes, the MSG's will both have the latest version in the GUI:
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.