Symantec EndPoint Virtualization Tips & Tricks

I've been collecting ideas that I want to write articles about and as I looked through my backlog I found that some of them don't necessarily require a home of their own, so to speak. And with that I decided to throw something together where I can discuss these various items in one place.

This article is by no means an end all to SWS related tips and tricks. Just a launching point for some goodies and a place I can revisit once in a while to provide more info. There is no particular order to these, although the first point I'd like to make I believe everyone is familiar with and plays a critical role when embracing a new technology in your organization, and that is the company culture.

For the next minute or so, I'd like to ask you take off your techie hat and try to visualize this from a management perspective. Without any doubts I can guarantee that anyone who has been involved with any form of desktop virtualization, such as solutions from Citrix, VMware, and Symantec will know exactly what I'm talking about. If I hit the nail on the head, please give me a thumbs up.

And so...some food for thought...

When problems arise it can be easy to blame the new technology. When considering you're adopting a new technology, especially one that is highly visible to the user community, be prepared to have approximately 95% of all problems blamed on said technology. The reason this happens has to do with a very simple but yet very complex to control factor and that is the culture in your organization.

Culture is not limited to award programs, company values, company events, team interactions and what is served in the cafeteria! Technology and how we use it in our organization plays a very large role in this culture as well. This highly important variable too often ends up being overlooked and in some cases becomes the downfall of a perfectly good product. As technology specialists and integrators we need to make this piece of the puzzle a large part of what we do. So that at the end of the day we aren't just deploying a new technology, we are also helping shape the end-user community's acceptance of the cultural changes to come. With that a huge part of our role changes from simply deploying a new technology, but to preparing the culture of the end-user community for new solutions.

Everything we do in IT is to help end-users be as productive as possible as quickly as possible for the businesses to achieve its goals. Keeping the end-user community properly prepared and properly managed through the transition can largely be handled with consistent and regular communication that is simple to understand, and is written in none technical terms from the end-users perspective. The tip here is be sure to consider your end-user community and what they will be looking at when they come in on Monday and their desktop no longer looks like it did on Friday. Even for something as simple, from a technical perspective, as a GPO change that enforces a Desktop Background. If the time is not spent to help the end-users clearly understand what all the implications of the coming change are and what the impact of this change will be, be ready for your helpdesk to get calls that the New Background is responsible for lost files and Windows crashing.

Of course, this doesn't and can't ever guarantee that 100% of the users will be prepared and not have any questions, but it will reduce your need to fight fires by a large enough percentage that you will be able to count dollars saved. Whenever I do implementations I always like to add a testing phase with a select group of users. I like to at minimum include at least one user from each department. This way I have a good coverage ratio for most applications and functionality in the organization. This will help me get a decent level of regression testing as well. Of course, with virtualization the concept of regression on the desktop image has changed since we can utilize isolation and just avoid those issues all together, but you still want to cover that slight chance that something may still not click.

When you do select end-users to help test, make sure you have some of the more vocal users who will not hesitate to speak up and let you know exactly where the problems may be. During this phase I have a chance, as an integrator, to learn about my end-users and how they are working with the environment. I can use this time to prepare my strategy for how I will work with them to get that acceptance my project needs to become a success. Make sure to also be proactive in helping the end-user community understand the business benefits of a new solution. We don't just want to force changes and tell everyone that this will be a better thing for your day to day.

We want our end-users to be a part of the process. Explain to them the business benefit, leaving the technical justifications out. When you involve people and make them feel like they are part of the entire process and their thoughts and opinions matter, you will find that this alone will help achieve success for your deployment. But don't forget, culture does not change overnight, It can take you one to three months to implement a new solution, and the quicker you get end-user buy-in, the less time you'll spend convincing your end-users that this new solution was in fact a good decision.

So, if you've chosen Symantec EndPoint Virtualization, you've taken a step in the right direction. "Now you know, and knowing is half the battle." Norton folks, that one was for you.

When thinking about your applications that have or will be deployed with virtualization and/or streaming there is one thing in particular that is important to keep in mind. These products are not made to change how applications function conventionally. To take an example, if some application requires a reboot when installing conventionally, it will, in order to function correctly after install, require a reboot when virtualized. The second part of that equation of course is when you've included the reboot, communicate this to your users and let them know their machines may require a reboot the first time this app is streamed, but also let them know that the business benefit is that they have the apps they need on demand and can get them almost instantly as company and users needs call for.

Our goal has and always will be to enable the highest level of productivity in our end-users, which in turn requires new and updated software. Before moving to streaming and virtualization, all applications were likely pushed using a silent install, and probably during a maintenance window. Chances were that there wouldn't be a reboot, at least not one that the end-user would be present for, and the user may have had to wait from one to several days before their trouble ticket or software request was answered.

In all implementation scenarios at the end of the day the application is installed, but there are differences in the various installation models. If you are brave and you went out there and physically touched every single desktop, installed the new application, you most likely initiated a reboot before moving on to the next one. Again, while done either during a scheduled maintenance window, or with the end user getting some coffee while you borrow his or her chair for the next 15 minutes.

Now we return to the streamed scenario. Here we have a solution that is not only incredibly efficient in that you can do this without having to schedule a maintenance window, but it can even manage licenses for everything you've deployed, to name one or two benefits. Now however, we have brought the final step of this deployment upon the end-user, and with that they are seeing a reboot, maybe pop-ups that are annoying them, etc. Since we’ve taken that important step and helped them understand that this new technology enables them to become immediately more productive, while saving their department money by complying with EULA’s, we have most likely avoided what is at best a minor annoyance of a reboot, turning into the downfall of our organizations biggest ROI. The only thing left now is all the recovered IT time that can be allocated to work on those other projects that are in great demand, such as upgrading or adding some cool new modules to SharePoint or upgrading the Wiki to the latest build.

Getting end-user buy-in upfront before the foot meets the pedal is a fairly critical part of getting the maximum value from the solution that you have spent countless hours testing and pitching to management, getting executive buy-in, and allocating budget dollars for. Isn't it ironic, how one of the major impacts to the success or failure of a new implementation is something that has little to do with the actual product being implemented? I always keep this in mind and try to use it to my advantage whenever possible by making the end-users stakeholders in the project success.

Consider this before, during and after implementations. It is important to know the app you are working with and how it is designed to behave, not just after install, but with respect to other conditions such as co-existence with other apps on the system. We always need to make sure to account for various criteria and before assuming we have a problem, the first thing to consider is how this scenario would play out in a conventional environment. If the same issue exists, it means that either there is a problem with the deployed app or some other app it is interacting with, or this is by design.

However, if there are no problems conventionally and the product behavior has a significantly negative change from conventional to virtualized and this behavior does not exist prior to virtualizing and/or streaming, then we need to dig in and figure out what's going on. But before you even get this far, always take into consideration how your end-users are working today and how you can deliver something new to them without creating a panic. Sometimes a big change is required, and there is no reason why this can't be a good thing. Just put in the extra time to prepare before hand to inform and train your end-users so that they will be ready and will know what to expect. After all, the cost of this pro-activeness is significantly less then fighting fires afterwards and possibly having to undo what you have worked so hard to implement.

I'll leave you with a little streaming configuration tip. The streaming agent installer contains a configuration file called setupCfg.txt. There are a number of things that you can control in this file, but for now I just want to point out one of them.

If you open this file in a text editor you can find the following entry:

; SWS.APPSTREAM_CACHE=C:\_AC

The semi-colon (;) means the line is commented out and will not be read by the streaming agent or used in any configuration.

If you want to specify a custom location for your streaming cache, just remove the semi-colon to un-comment this line and change the path after the "=" sign. It is not recommended to use a long path as it may negatively impact performance.