Standardization of Desktops in an Enterprise Environment
Novell Cool Solutions: Feature
By Julian Greenwood
Digg This -
Posted: 26 Jul 2000
Current version: ZENworks 2
Part of the problem of every IT department is dealing with what is at the user level. Namely the desktop. In most enterprises you'll find a lot of different applications spread across different departments and divisions, and applications are being delivered to the desktop in a multitude of ways. What IT departments also have to grapple with is the acquisition of new companies by the corporation, and integrating these new companies into the existing corporate environment without undue impact to the existing corporation, or to the newly acquired company.
This article gives a quick overview of the concepts and benefits of standardization of desktops in an enterprise. The scenarios are based on an existing multi-desktop environment with no standard, or limited standards, in place. Implementation will use the Novell operating system and ZENworks.
When an IT department starts to look at streamlining deployment of applications, and standardization of the desktop, it can be a daunting task. Part of the reason for this is the lack of standards in place, and also the integration of different divisions into a standard mold that the corporation is envisioning, and the multi-dimensional impact of a project of this size while trying to get agreement on a standard. Hopefully this document will give some basic pointers to what needs to be done and what needs to be agreed to.
One of the first things that need to be done is to get a list of all people who will be involved in the project. The list must then be sent to everyone involved. This includes the people involved at the decision level, the technical team, and the implementation team.
Once you have this list you can then start to have meetings to decide what your company's standard desktop should look like, and what applications will be required. Part of this process is to gather a list of all applications used by your company. Then have the divisions list the number of users in each division that use the application, and indicate if the application is core to the division or not. From these lists you should end up with a set of applications that are core/common to all divisions, which will be part of the standard desktop. You will also end up with a list that is core/common to a specific division but not core/common to the company as a whole.
In your environment you may have multiple ways that a user receives applications and updates. From a technician going to the desktop and installing the application, to the application being delivered to the desktop via ZEN by direct association or via a group or container association. Part of the solution here is clean-up of delivery method by setting the standard as ZENworks.
Before we move on let's list what we have so far.
- Identify all necessary applications.
- Create teams that need to be in place.
- Assign project leaders and enlist appropriate decision makers.
- Resolve what is core and common on corporate and division/site levels.
- Install ZENworks as the standard delivery method of applications and updates.
Ok, we have our lists and teams in place so now comes the implementation of the project.
This involves the creation of Application objects for every application that your corporation uses. If they are already created then you will go into the testing phase once everything has been standardized (naming and Administration notes). You should concentrate on the corporate core/common first, as this will give you the basis for everything else. You must also have a testing plan in place for these new application objects at every division/site in the corporation. At the same time your Technical team should be gathering information on existing groups, login scripts and users.
There are two approaches to the Implementation phase
- Front end loaded clean up
- Back end loaded clean up
Note: Approach Number Two is the straightforward implementation.
Approach Number 1
You have a user in finance at New York. He is a member of a group that gives him ten application objects and rights to two servers, and the login script references the group for drive mappings. You have decided that you want your standard desktop to have all applications come down to the Start menu with foldering.
Six of the existing ten applications are local and are not part of your standard desktop, or divisional- or site-specific. When you move this user out of the group and set him up with the standard he will lose rights to servers, drive mappings and the six applications that are local. How do you resolve this?
- You create a migration group that has exactly the same rights as the old group. You copy the existing six application objects to a migration container and you set these up with foldering so that they are included in your standard desktop even though they are not part of the project.
Remember here that you must allow for pieces that are not part of the standard to become part of the standard or at least have a place to fit in. Part of your problem here also is the GUID of copies of existing Application objects not matching the GUID of the original. The only way to overcome this at the moment without having verification or a re-distribution is to use a tool from Performing PC's called ZENith. If you do not synchronize the GUID to the original somehow, you will have verification all over the network. Very ugly in a 10,000 user environment.
- You will also have to change the login script to allow for the new groups.
- Clean up will take place when everyone has been standardized at a site. You will go through and remove unwanted Application objects and groups and rewrite the login script.
As you can see this is a prerequisite for the standardization of desktops, and something that must be handled with care as you are now touching the production environment.
Rights for a group can be extremely complicated and we suggest using Bindview or another such product to run tree-wide reports first for a list of groups that have applications associated with them, then a report on these groups for rights.
After deciding on a standard desktop and that all applications will be delivered via ZEN, you will also have to allow for Application servers. These servers will hold all application software and the ZEN fil files for each application. You will have creation of application objects and this must be to a standard as well. You must use the Admin notes to enter information on when this AO was created; by whom; where all of the underlying AOT/AXT and fil files are located; and what type of application it is, as some naming conventions can be very esoteric.
Another thing to remember here is that you will be setting up a few new groups. These will be:
- Core Applications
- Common Applications
- Site Applications
And you will be setting up foldering as well.
Not all applications will be in these groups as you will have applications with direct association to the user. You will also have direct association to some applications but these applications will be in your standard foldering scheme, and this is set in the application object. The idea here is to clean up the desktop not add more clutter.
Approach Number 2
You will follow the same principles as in Number One, but this time you will enable foldering across the enterprise first. This will affect all users in production (you can do this per site if your tree allows it.)
Here you will remove the duplication of groups, group rights from the project. You will still have to copy the existing Application Objects and synchronize the GUIDs. But with this scenario you will not have to do the entire up-front creation and manipulation of the production login scripts.
Technicians will be able to learn a desktop that applies wherever they go in the company. Also the Help Desk will know where an application is on the desktop and how the users receives the application. These benefits alone make this a worthwhile project.
But you also get standardization in Novell Directory Services as well. Because now you have standard groups and standard folders, and for administration purposes you have removed a large amount of dead wood, like old groups and old application objects, and a lot of rights that no one needed, or were associated to a group but are not needed now. Your login script should be a lot smoother, and user login time will be reduced because they are reading fewer groups and walking the tree less.
So let's recap what we need:
- Discovery of applications
- Teams that need to be in place
- Project leaders and decision-makers
- Resolving what is core and common on corporate and division/site level
- Server requirements
- Creation of Application objects
- Creation of new containers for application objects
- Creation of new groups
- Creation of new folders
- Creation of new scripts (only if ApproachNumber 1 is followed)
- Rights reports
- Groups reports
- Testing procedures for application objects
- Testing groups for sites
- Roll out of new desktop
- Clean up at site
That about covers the quick overview of a Standardization of desktops in an Enterprise Environment.
Julian Greenwood is a member of the ZENworks Cool Solutions Board of Review. He has eighteen years of advanced training and experience in network systems installation and configuration. He's worked with ZEN from its early days as Intel LanDesk through ManageWise to the current ZENworks 2. He has extensive hands-on technical experience with installing, testing and maintaining network operating systems.
Julian has worked for various organizations from Her Majesty's government in the UK to his current position with Bristol Myers Squibb Pharmaceutical company in the USA working on the implementation of desktop standardization and the rollout of ZENworks 2 with over 750 applications.
If you have any questions you may contact Julian at firstname.lastname@example.org
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com