The new Configuration Manager Application Catalog represents a great opportunity for you to deliver self-service application installation to your company’s users. By modeling the applications and publishing them in the Application Catalog, you can offer up a service that makes installing applications quick and easy for your end-users. Because the Application Catalog only shows applications that are deployed to the user, your end users also get a tailored experience just for their job role. To make the most effective use of the Application Catalog and ensure you’re delivering the best experience possible, here are a few tips we’ve learned from real world deployments.
Site System Role Installation
If you’re hosting less than 10,000 users in your company’s intranet, co-locating the Application Catalog web service and Application Catalog website roles on the same server should work just fine. Remember that the web service role connects directly to your database, so ensure that the network connectivity between the SQL server and the Application Catalog web service servers is robust. Refer to the product documentation for specific scalability guidance.
If you’re hosting more than 10,000 users, or when you have more geographically distributed users, consider deploying additional application catalogs to keep responsiveness high and user satisfaction up. Use client settings to configure collections of computers to use different Application Catalog servers.
For deployments with two or more primary sites, it helps to have at least one set of Application Catalog roles per primary site. When you configure the Computer Agent client settings, set the Default Application Catalog Website point value to Automatically detect and the system will take care of assigning the local Application Catalog role for clients in each primary site.
For deployments that need to scale out, (especially as it relates to Application Catalog performance) it’s better to scale out by using separate primaries rather than installing a second Application Catalog role for the same primary site as the existing Application Catalog. Doing so will allow the Application Catalog web service roles to communicate with a different SQL Server database and provide a better end user experience.
The User Experience
The Application Catalog has code running in the browser but the user’s experience is heavily dependent the data exchange with the catalog web server. Some caching takes place on the Application Catalog web roles for performance optimization, but several factors influence the overall performance and responsiveness of the Application Catalog:
- Number of applications for a user – The Application Catalog is designed to return a sorted list of applications for a user one page at a time. Users can also limit that list by a search criteria, or a category. Regardless of the method they use to see their list of applications, the system has to build out the list, sort it, and return a page of applications to the user. For an Application Catalog that has 1000s of applications, it will take longer to fetch and sort the list than if there were less than 100 applications published. So, as you’re deploying applications, periodically review the applications published to the catalog and remove deployments for outdated or obsolete applications.
- Number of distribution groups (or security groups) the user is a member of which are used in creating user collections – When you deploy an application to a user collection, you can either deploy to “All Users” or a custom user collection. Deploying to the “All Users” collection provides the fastest user experience because the SQL query is very simple. When you deploy to a user collection that’s based on direct members or distribution/security groups, the system has to build a much more complex SQL query which includes a list of the user’s distribution group ID’s – and that will take more time to send to the server and process in SQL. Be conscious of this as you deploy your applications. By all means, deploy your applications to user collections that represent the audience for that application, but for those applications that are truly available to all users in your organization, you can offer the best possible user experience by deploying those applications to the “All Users” collection.
- The network connectivity between the user’s computer and the Application Catalog website – The Application Catalog transfers a lot of information between the users’ computer and the web server during a normal session. When a user is connected over a slow network, their experience may be degraded. You can deploy additional Application Catalogs in network segments that are closer to the users to improve their experience. Each user sees their personalized list of applications from any Application Catalog server. Some network connectivity factors may simply be out of your control, so it’s helpful to give your users information and set their expectations appropriately if they frequently connect over slower networks.
- The number of users currently using the Application Catalog – For most organizations we’ve talked with, installing software isn’t an activity that end users do several times a day, and probably won’t even do it several times per month. However, there is a more common scenario that will cause a spike in usage on your Application Catalog. When you’re rolling out a new application, it’s typical that a large number of users will start installing it immediately after an announcement. You can stagger announcements (and even enforce them by deploying to collections of users that mirror your announcements) to avoid a super-large spike in Application Catalog usage that would impact the overall user experience.
Tell me about the applications!
Great descriptions for your applications are critical. It’s amazing to watch users browse through a screen full of text. Some users are very deliberate and read every word, but most simply scan for key words. Some users use visual recognition of the application icon. Whatever the style of user, plan to accommodate the most typical ones as you fill out your Application Catalog metadata. Here are some specific best practices:
- Have a great one-liner! Make the very first line of your description concise, easy to read, and to the point. That is what shows up in the description preview for the application, and your users can quickly scan that one line.
- State key requirements. The Application Catalog will tell users if their computer doesn’t meet requirements for the application. But, you can also help your users by including any unique or critical requirements in the description. For example, “Requires Windows XP Tablet Edition”
- Import icons. Many users will appreciate the visual reference to the application and can quickly find an application using icons.
- Extend the description. The Application Catalog has a URL associated with each item. If you have lengthy installation instructions, training guides, approval requirements, or other documentation that doesn’t fit well in the description field, point the “User Documentation” URL to your internal website for the application. Set the “Link Text” string to match. For example, set the link text to: “Detailed installation instructions” and set the User Documentation URL to your internal SharePoint site or an internal knowledge base article for that application.
Thanks for making it through this blog! You now have some new tools at your disposal to deliver a great self-service application catalog to your users.
For more information about the Application Catalog, see Introducing the Application Catalog and Software Center in System Center 2012 Configuration Manager on this blog, and Configuring the Application Catalog and Software Center in Configuration Manager on TechNet.
This posting is provided “AS IS” with no warranties and confers no rights.