RG03C – App Standardization = Automation Manager

By Sascha Maier

 

This article was written with both high-level management and IT Staff in mind. It describes the approach of how to standardize your client environment and application set to generate economies of scale and business synergies. The RES Automation Manager is the right software for this strategic goal. The article came to mind during the last weeks, as I over time have observed the need in many companies for a standardized application and client platform. Gartner formulated this need in a recent article, as referenced below. Beyond formulating the need however, very often the questions remaining though are: How? What is needed? I will be describing the need and process using the RES Automation manager to reach the end goal in an application standardization project.

It’s true that many companies have attempted to standardize in the course of a VDI/TS implementation. However, it is often the case that many companies have the process of standardization in front of them, because they do not plan to move to VDI. Therefore the standardization of FAT client’s incl. standard applications is a good alternative. Alternatively, if you have VDI/TS in use what about your laptops and Desktops then? Could it be that these machines generate more work than all the rest together? I have done this kind of project back in 2008 in a global company using the RES Automation Manager which was the key to success.

I will first describe the high level perspective including the pro’s and con’s and then dive into the RES Automation Manager, which can support and execute this process. This article contains exerpts and quotes from Gartner article G00201322.

 

Why application standardization?

Application standardization reduces the complexity of the application landscape, by getting as many groups of people as possible to use the same application for the same task. It is usually part of a broader business-led initiative to standardize business processes and data across a large, global enterprise.

Most important points:

  • Application standardization is driven by a corporate goal to standardize business processes to achieve economies of scale.
  • Groups that are used to having autonomy will fight off standardization without strong executive leadership.
  • Standardization is not the answer if business units differ too much. Do not standardize just for the sake of standardizing.
  • Standardization can cover only a subset of business processes or only a sector of a large business.

Recommendations:

  • Use application standardization as a lever to accomplish business process standardization in the context of the business transformation program. In plain english: Try to grease the wheels by making this part of your business plan and understand where the business synergies are to develop a business case for application standardization.
  • Don’t fight an uphill battle – application standardization is never going happen if top management doesn’t want it.

 

Good Reasons to Standardize Applications:

Application standardization is almost a requirement for a company to operate in a unified fashion globally. It allows information to be shared, processes to be distributed and common settings to be applied across the board. The leadership teams may embark on a “one company” initiative to leverage the company’s people and assets more effectively and grow geographically. Application standardization is used as a catalyst to force organizational and process change.

  • Top executives usually have many reasons to move to a one-company approach; all seek to exploit economies of scale and commonality among the business units. Some of the common reasons include:
  • Can’t leverage size/scale. Many companies have grown by acquisition, buying businesses in adjacent markets in their home territories to expand their offerings and similar businesses in other regions to become global. Until they change the local operating structure, they are simply running a holding company and won’t realize the synergies of the merger or acquisition.

Single face to the global customer. Global customers get frustrated when they need to deal with separate sales forces for each brand and region of the world. If they operate consistently globally, they want their suppliers to also do so.

Move from national/regional to global business. As with the customers mentioned above, companies are creating global product and service organizations to reduce duplication of administrative, sales, supply chain and R&D efforts. They seek to optimize these functions on a global basis.

Many similar operations. As companies try to consolidate, they find they have many similar operations around the world, such as sales offices, factories, distribution centers and stores. Two opportunities exist: consolidating facilities regionally for efficiency and tax advantages, and standardizing business processes to drive efficiency.

Brand and product/service consistency. As companies expand globally, they want to leverage their brands across a wider area. Maintaining the brand promise is always hard, but is even harder if processes vary too much.

 

Bad Reasons Not to Standardize

Where there is a tradition of local autonomy, business units will use any excuse to avoid corporate standardization efforts. This is one reason why a strong C-level effort is required standardization to succeed — business unit leaders need to be convinced and given incentives to do what is right for the overall enterprise. The change management issues are huge, and extra management effort is needed to overcome common excuses like:

“We’re different.” Every company or business unit thinks it’s unique and needs to do things its own way. But the issue is often “We’ve always done it that way!” You need to set the bar high on process differentiation and, rather than impose a process, lock the affected business unit process leads in a room until they agree on a common process that will work for all of them.

“We have to do it that way due to government regulations.” This is a favorite of country-level organizations resisting regionalization. One effective way to test this is “Show me the text of the law or regulation.” If they can produce the regulation, an objective discussion can be had on how to comply. If not, this devolves into the “We’ve always done it that way!” issue.

“Our division/region/country has always delivered its profit and loss (P&L), so leave us alone.” A company with a strict P&L culture breeds insular behavior at the P&L level. The unit manager wants complete control of all the resources necessary to deliver the P&L that affects his or her bonus.

The fourth excuse can very well be summarized as “All of the above” It usually covers a hidden agenda for individuals resisting change, as it’s being perceived as a thread to job security. You will typically encounter these types who vehelmently will defend the ability to write code or scripts to their dying breath. No matter what you suggest to improve operations the reply is “yeah, but I could write a script for that” or “I’ve made a utility to deal with that” and so on. What these types are really saying is “Hey buddy, I’ve invested a lot of time and effort into making myself irreplaceable by making my company depend on me and my solutions. Don’t you dare come in here suggesting changes that could simplify operations and destroy my little Fiefdom.”. As outlined in this article, Fiefdoms are some of the most dangerous things to a company’s health, growth and general viability. Be very vigilant if you’re up against a local “Feudal Lord of IT”.

 

Good Reasons Not to Standardize

Standardization isn’t for everyone though. Sometimes a holding company approach is the right way to manage a portfolio of independent businesses. Other times, the company and its management are not ready (or desperate enough) for the cultural change required. Good reasons not to standardize include:

Sluggish C-level commitment. If process standardization is not a corporate strategic objective, driven by the CEO, then don’t bother. You’ll be pushing uphill. This also ties into the earlier reference to Fiefdoms. If there’s no support from top level management to clear these types of roadblocks, then forget about it. It’s never going to happen.

No strategic goal/benefit from standardization. It isn’t worth doing application standardization just for the IT benefits alone. It costs too much money, time and political capital.

Large diversified sectors. Standardization only makes sense if you can take advantage of the commonality of customers, suppliers, materials, services and processes. A $40 billion company may choose to standardize within each of its $10 billion sectors, if the businesses are different enough.

Very different value chains. A division serving the fast-moving consumer goods market will have very different requirements and cycle times to one that is building capital equipment or providing financial services.

Strong cultural differences require different management styles. Some cultures may be more open to entrepreneurial methods, while others need strict hierarchies to function.

Different brand promise. Processes may be intentionally different as part of a product segmentation scheme. For example, one brand may offer low-cost, limited options and self-service, while another brand provides high-touch service and technical consulting.

 

Turning it into reality:

Now let’s switch our focus to the technical part of this article, specifically on how to realize standardization. You as a manager need to align and transform the strategy goal into an executable project for the IT staff. The RES Automation Manager can do all that and more for you. Below is an outline of the ten step approach, which we will detail for throughout the remainder of this article:

1. Deploy the RES Automation Manager agent to your existing environment.

2. Build groups of PC’s (Based on Departments, Locations, Countries, Business Unit or whatever)

3. Scan installed Software on each PC in each group.

4. Extract results of the scan and build a list for each group/department

5. The most challenging part: Consolidation

6. Define a standard application set (1 piece of software for one task)

7. Build packages / migrate / virtualize

8. Migration -> re-installation -> On every new PC

9. Embedded RES Automation Manager Agent into the corporate image.

10. Bind Automation Manager Teams to Projects.

 

Step 1. Analyze the existing environment

If you are new to the RES Automation Manager, the first goal is to push the AM agent to the clients in your environment. If you already have AM in use, please proceed to step 2 or check out the new free Baseline Desktop Analyzer which can add tremendous extra value during this process.

The AM Agent can be distributed by several means. First up, it is possible to push the agents service out to the clients directly. This method is fine for environments where there is direct network access to the target computers. The push method requires access and credentials to the ADMIN$ share on the target computer. If there is a personal firewall in effect, it must be tempoarily lowered for any push-type deployment to work. Once the agent is pushed to the target computers, the firewall can be raised again, since the architecture is pull-based all the way through.  In the AM console, go to Infrastructure-> Agents, Click add and specify the target computers as shown below. You can optionally browse or scan for target computers, using the button.

Alternatively, you can use a GPO or any other software deployment method available within in your environment. This method scales better as you are not hindered by existing personal firewalls as policy based installation items would bypass that. Here is how you would extract the preconfigured Agent as MSI file. In the AM Console, go to Infrastructure-> Setup -> Components -> Right click on the Agent and choose “Save component as…”:

Select “Preconfigure setup for the Agent” so the Agent gets all necessary information to connect automatically. This information is written into the .MSI file, which is then signed and saved. IMPORTANT: The agent communicates to the dispatcher on port tcp/3163. (Refer to this article for RES ports in general) To establish initial connection dispatcher, the agent needs to perform a Multicast on IP port 3163 over the network. This will work fine if there is a dispatcher present on the same subnet as the AM agent. If not, you need to configure the Dispatcher Discovery section in the preconfiguration settings.

Save the preconfigured MSI file and start distribution using whatever means you have at your disposal. After a while, the AM agents will populate in the console, under the Infrastructure|Agents node.

 

Step 2. Build groups of PC’s (Based on Dept, Locations, Countries, Units, etc)

This part depends heavily on the structure and size of your organization. Keep in mind that it also depends on your standardization strategy as mentioned above. Typically you would have: Department, Location, Business units and Suppliers to name a few. It is however important to group the PC’s right, because only then will you get good results for the consolidation process. It is expected that you have an overview which users are using which computers in which department – If not you have to prepare that. The RES Desktop Sampler may provide help building this overview. In the RES Automation Manager, groups of computers with agents on them are known as Teams. Here is how you build them:

A) Go to Infrastructure -> Teams and select Add:

B) Choose a name for the team which describes it best:

C) Choose the right members for the team.

Now you will have a list of Teams at your disposal:

 

Step 3. Query installed software in each Team

The next step is to build a module which scans the computer groups (teams) for installed software. You can use the Automation Manager or the previously mentioned Baseline Desktop Analyzer service from RES for this. Here how to use the AM for this task:

A) Create the module. Go to Repository->Modules -> Add Module and select under Task -> Provisioning -> Windows Installer Package. Here’s a tip for you. When you get familiar with some of the 120+ tasks and Queries available in RES Automation Manager, use the Instant Search field, located at the top of the task selector. This field will weed out the search results as you type. For example, just try typing install and see how the list is shrunken down to anything that’s relevant to this word.

B) Schedule the Job and run the module. I can recommend using the ”After next boot” because it’s more or less sure that not all PC’s are currently online and for this process you need to cover all of them.

C) Select the right Team to scan. Note: It actually makes sense to first schedule a scan across all teams so you know from where you start. As an example, when I did this in a recent customer project we found more than 1.000 different Software installations for 1.200 Users!

 

Step 4. Extract scan results and build a list for each dept.

A) Go to the Job section and extract the results of the Installed Software query:

B) At this point you can save the results as an Instant Report in PDF format. Alternatively you can also export the result as either .TXT or .CSV format. This will alow you to further process the acquired data, for example in Excel:

 

Step 5. Consolidation

This part is by far the trickiest part of the project. The primary reason is that you have to find the right software for the right task. By task I mean business tasks, i.e. the stuff the company is trying to do. There is no universal approach or recommendation here, as every company is different. The secondary reason this step is challenging is that it’s here the rubber meets the road in terms of corporate politics. One thing is for sure though: This part of your standardization project will need a “Top-Down” approach. In other words; it will need to be decided, signed and communicated by the top management, because this enables you to drive this process.

I can quickly explain how we did it. In the project from which I’m sharing my experience here, I had to cover approximately 25-30 Departments. In advance I prepared a list for each of them. I scheduled  appointments with each department manager and I sent them a copy of the application list (incl. PC/Usernames) beforehand. This way they had a chance to discuss it internally before the negation started. This worked out quite really well, except for the main application which was in my case CAD applications and different Adobe versions but even at this point we found a solution. The concern was that when they switch to a newer corporate version they need additional training and some customization of the app may not work properly if they use the new version. You are likely to hear a million reasons ;) Take them one by one and use for example the 5-Why’s questioning strategy to find the real reason of the concern. In the end we came down from to 1.000 to 150 different applications by using this method.

 

Step 6. Define the Standard Application Set

Yes, in the mentioned standardization project which I was involved in, it was indeed a hard fight. We had to spend some extra money for training and additional licenses, but we got it done eventually. This step is the time where you finalize the new corporate standard application set and let each department manager co-sign the document.

 

Step 7. Build Packages / Virtualize / Migrate

Once the sign-off process has been completed, it’s time to decide how to deliver the new application set to the users. This again depends on your delivery model. If you use Citrix, TS or AppV you will need to publish the new application set one way or another. Here the RES Automation Manager can also help you manage the delivery, but you are much better off using the RES Workspace Manager, as it is capable of publishing applications through Citrix Xenapp, Terminal Server 2008 Remote Apps, and manage App-V/Thinapp/CitrixStreaming virtual applications. If you use MSI files or any other software, such as unattended setups which is supported by the Automation Manager you can use AM to push the Software to the clients. RES Automation Manager also has the capability to preload virtual applications into the cache of App-V clients. Below is an example how to import the Standard Application set using MSI files.

A) Import the application installation files for deployment as Resources in Automation Manager. In the example below, we’re just importing a bunch of MSI files. Here’s a little tip: You can batch-import multiple MSI files at once. After you hit the browse () button, be sure to select all files at once. When you hit OK, a new resource will be created for each file.

B) In resources you can now verify all uploaded files. Note that some application installers may come as multiple files. In that case it is adviseable to use a Resource Package instead.

C) Now you can create a module to deploy the imported Software. You could in theory create one module to deploy all packages or you can create a module for each software deployment task. The last method is the advised approach as it’s a lot easier to update modules with newer software versions. If you want to group multiple modules together in Automation Manager, this is done using the Project object.

D) Define if necessary the security context credentials to allow AM to install the software. It’s only in rare cases you would need to specify alternative credentials. Per default Automation Manager will run MSIEXEC.exe with the Local System account credentials, which is often more than enough to get a piece of software to install correctly. Also you may need to specify  parameters required for the MSI file to install.

 

Step 8. Deployment

Here comes the next challenging part of the project – the deployment. No one likes it when you take something away and naturally most people hate changes. However, at some point you have to execute the migration of the new Standardized application set. You can schedule it on top of a migration to a new OS or you can decide that from now on every new shipped PC will only contain the new Application set. In other words, you have to draw a line when the new standardized application set is delivered, moving forward.

 

Step 9. Embedded AM Agent in the corporate image

Embedding the agent means; when a new corporate computer comes online, the agent automatically registers at the nearest dispatcher and receives instructions accordingly. This is a really good way to automate the new deployment of the application set for newly installed clients. You could for example use WDS (Windows Deployment Services), which comes free with Windows 2003R2 and up. Any other imaging/bare metal deployment tool can likewise be used.

A) Prepare Agent for image. This functionality allows you to include a RES Automation Manager Agent when you prepare an image of a computer. When you first prepare a machine template using this method, Automation Manager will create a dormant Agent on the target computer. The reference to the agent is also removed from the AM datastore. When the sleeping new Agent detects a change in the computers name (typical by way of a Sysprep or similar), it will start automatically and register itself in the AM datastore, via the nearest dispatcher with the new name. If necessary, you can also specify an AM Project or Module in the image, which are then executed as soon as the new Agent comes online. I will use the Team rules to execute additional department Projects automatically. Here is how to prepare an agent for imaging:

A) Go to the Agents node and right click on the Agent of the “reference machine” (that is the machine you will clone later)

B) Click Prepare for Image to start the Wizard. The rest is self explanatory.

C) Now it’s time to select a project which will be executed automatically when a new Agent connects the Datastore. Further down I’ll be explaining how to create a Project.

D) Once the Wizard has finished you can start creating your Master image from the reference Machine – IMPORTANT: As mentioned above, the selected Agent won’t show up again in the Console!

 

Step 10. Bind Projects to Teams

At the end of deployment you will quite often find yourself in a situation where you will have variations on top of the corporate image like some small sub sets for particular departments. Take this example:

  • Basic corporate application set (for all employees) = Office, Adobe Reader, ERP Software, AV, etc. This is the lowest common denominator set.
  • Marketing = Basic corporate + Adobe Professional, Social Media tools, FTP Software
  • Engineering = Basic corporate + CAD package, CAD Viewer Software

Now you have the capability to schedule installation of the standard set onto the agent as described above and select for each team a particular Project which will be executed when the agent shows up in the team. Here’s how to do it:

A) Build the Project for the different teams

B) Bind the project to a team so it will be automatically executed when an Agent connects the Datastore. In other words …when you push the corporate Image to the new Client the AM will automatically recognize that it’s member of a team. It will start the scheduled project for deployment. Go to “Automatic Job Scheduling”

C) Select the right Project for the right Team:

Now the AM Project will be scheduled automatically when a new team member shows up. By setting up Team rules, you can add Agents as members of a Team automatically. Team rules are based on the specification of the computer on which the Agent runs, and are evaluated each time the Agent comes online. If an Agent meets the rules of a Team, it will automatically be added to the Team. If it no longer meets the rules of a Team, it will be removed from the Team. The Rules button shows the number of configured Team rules in brackets. Example: If you have a computer naming convention in your organization you can setup rules so the new computer will automatically recognized as a member of a team based on parts of the computername.

It is my ambition by sharing this document as a template, your standardization process will be a success and will save a lot of unnecessary work in the future, give you more resources to deal with the real challenges. As discussed on the subject of resistance to change; some people won’t like things changing from day one. However it is my experience that after a while they will love it, as they can exchange documents inside the company without version conflicts. Second the admin staff benefits greatly too, as upgrades can be tested and deployed in a stable and easy way.

2 Comments

  • By J.W.G. van Gennip, May 1, 2014 @ 06:18

    Can you explain what the “prepare for image” actually does on the machine. We have made a project to sysprep our “image machine”. In this project we would like to prepare the RES Agent for imaging. Because it is called Automation Manager we want “prepare for image” to be done automatically and not by hand in the properties of the agent. And you want to “prepare for image” be executed before you run sysprep /shutdown. This will be a because “prepare for image” delete the agent in the console and the project will stop.

    We made a snapshot of the “prepare for image” action to see the changes in file and registry on the machine. Most of the changes took place in hklm\software\wow6432node\res software\automation manager\agent and wisdom\agent .
    So we made a module for our sysprep project to delete/modify the following keys.
    “CommuniationID”
    “NETGUID”
    “Prepared4Image”
    “Invokeproject”

    But allas after we capture the syspreped machine and restore it again on a machine no new agent shows up in the RES Console.
    We have also deleted the agent of the syspreped machine in the console.

    I thought I read somewhere that when the RES Agent detects an new ComputerName it will trigger an action to contact the RES AM envoirement to create a new agent.

  • By RESguru, May 1, 2014 @ 06:26

    Hi there, It’s been a while back since I last used this option as it was designed originally for Ghost deployed images). As far as I remember, the prepare for image option will do the following, as you have pointed out:

    1) the selected agent will go dormant
    2) it is removed from the list of agents
    3) then you make an image of the computer where the agent is now dormant
    4) when the image is re-deployed and the computername changes by way of a sysprep, ghostwalker etc, this prompts the agent to wake up and re-register itself.
    If it’s not doing what you are expecting, perhaps it would be a good idea to have our friendly folks in support have a look at it?

    Hope this helps,
    /Max

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment

Comments are welcome as always. Just do the math below. * Time limit is exhausted. Please reload the CAPTCHA.