Although it has become more common to host applications with a service provider, administrators looking to retain full control over their apps are better off hosting them on-premise, either by installing them in a private cloud
Public cloud computing providers offer subscribers as much flexibility as they can, but their first commitment is always to the security and stability of the cloud infrastructure. This means limiting the degree to which subscribers can manage hosted applications.
Blocking application patches
One of the ways service providers limit the degree of application management is by blocking subscribers from installing application patches.
Organizations often outsource applications to cloud service providers in order to free themselves from the burden of managing the application. Many administrators are all too happy to walk away from their patch management chores. Even so, turning over the patch management responsibilities to a service provider can be a double-edged sword. Remember, a service provider must ensure application stability if they want to stay in business. As such, they are likely to be very meticulous in their patch testing, and it may take a while before a newly released patch is applied.
While there are benefits to stability, there are also times when patches might be needed before service providers deploy them. This can be especially true for "unreleased" Microsoft hot fixes.
There have been times over the years when troubleshooting led to the discovery that a corrective patch is available, but Microsoft isn't ready to release it to the world. In these situations, the solution is to call Microsoft's technical support department and specifically ask for the patch. Needless to say, the odds of a service provider agreeing to deploy a patch that Microsoft isn't even ready to officially release are very slim.
No customized hosted applications
Another way cloud service providers retain control over hosted applications is by not allowing subscribers to customize them. This doesn't include using an application programming interface (API) to develop an add-on to an application -- although that wouldn't be allowed either -- but something as simple as a registry tweak.
For example, Outlook Web App has an issue with expired passwords. If a user's password expires, Outlook Web App will note that their password is incorrect and block them from logging in. In Exchange Server 2010 SP1, however, it is possible to create a registry setting that changes the way Outlook Web App responds to a user's expired password. Rather than denying access, the modification forces Outlook Web App to tell the user that their password has expired and gives them a chance to change their password.
As you can imagine, this particular registry tweak can be extremely beneficial. It can increase productivity while also reducing the volume of help desk calls. This option probably would not be available to anyone who accesses Outlook Web App through a public cloud, however, because no cloud provider in their right mind would allow subscribers to make registry modifications.
Limiting user configuration modifications
Finally, different service providers have different policies regarding the way that they manage user specific settings. Microsoft Office, for example, has a number of different options that a user can configure in an effort to control the way that Office apps behave. Some cloud service providers will allow users to make these types of changes, while others reset applications to a pristine state after a user disconnects.
Resetting helps to ensure the integrity of the application, but it also means that any changes that have been made are completely undone. This can be frustrating to the user.
Cloud service providers can reduce an administrator's workload by taking on the task of application management themselves. Even so, the limitations imposed by a service provider can also interfere with an organization's ability to use an application in a desired manner.
About the author:
Brien M. Posey, MCSE, is a seven-time Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information, visit www.brienposey.com.
This was first published in December 2010