Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Virtualization Community Blog

Setting the SVS User Logon Hook's Registry Flags

Created: 06 Oct 2006 • Updated: 29 Jul 2010 • 9 comments
dbethers's picture
0 0 Votes
Login to vote

If you thought the Login Hook code was cool, wait until you check out these examples provided by SVS Guru Dale Bethers.

Hopefully these examples will help those who are having problems configuring the SVS User Logon Hook. First we will look at the "Filename" and "Url" registry values and then the "LoggingFlags" registry value.

"Filename" and "Url" Registry Values

The "Filename" and "Url" registry values tell the SVS User Logon Hook were it should look to find the configuration file. The "Url" value takes precedent over the "Filename" value, meaning that if there is a "Url" value, the SVS User Logon Hook will always look there first for a configuration file. These registry values do not affect SVSUserAdmin. SVSUserAdmin is basically a specialized XML file editor. It will open any file it is told to open no matter where it is. Also it will look for the files in its "Recent Files" list in same place they were the last time they were edited, regardless of where the "Filename" and "Url" values are pointing. The registry key the values should be created on is "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Virtualization\Winlogon\VzUserSwXml" as shown in the following screenshot. You will need to create the parent key "VzUserSwXml" first; it is not created by default.

If the keys and their values are not created in the correct place with the correct spelling, you will see the following error in the error log (which we will talk about in just a minute.):

      Error parsing XML file VzUserSwXml.xml on line 0: The system cannot locate the resource specified.

If the SVS User Logon Hook doesn't find the appropriate registry key and value, it will by default look for a file called "VzUserSwXml.xml" in the "%WINDIR%\system32" directory, if it doesn't find the default file either it will log the message above.

In this version of the SVS User Hook, the "Url" value must point to an HTTP server; UNC paths are not supported. The configuration file can exist anywhere on the HTTP server that is addressable by a Url. Also it is not necessary to have both a "Filename" and "Url" value if both are not being used.

"LoggingFlags" Registry Value

The SVS User Logon Hook can be configured to log messages to the system event log; which can be viewed by right clicking on "My Computer" and selecting "Manage" and then selecting "Application" under the "Event Viewer".

Other application may also be logging events; the events logged by the SVS User Logon Hook will have "VzUserSw" set as the source.

The SVS User Logon Hook divides events it can report into four groups:

Event Type   Hex Value   Binary Value  
Information 1 0001
Error 2 0010
Warning 4 0100
Verbose 8 1000

Any combination of event types can be requested by setting the bits for the event types you want. For example to request Errors and Warnings you would get hex 6 (binary 0110). If you want to avoid bit twiddling or hexadecimal math you can just set the registry key value to hex F (binary 1111); which will give you all events types.

The "LoggingFlags" value is created on the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Virtualization\Winlogon\VzUserSw" as shown in the following screen capture.

I hope this has helps answer some questions.

Comments 9 CommentsJump to latest comment

Bo Faurholt's picture

Hi
just a minor correction.

the registry"paths" in the text should be:

"HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\
Virtualization\Winlogon\VzUserSw"
"LoggingFlags"=

"HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\
Virtualization\Winlogon\VzUserSwXml"
"Filename"=
"url"=

The screen captures show the correct locations.

Also, I'm using a UNC path for the configuration file and it works like a charm.

/regards
bo faurholt

0
Login to vote
dbethers's picture

You are exactly right on the registry paths. I think it is this exact type of typo that are causing some people configuration problems. So, thanks for spotting that and pointing it out.

That's good news on the UNC paths. We have not tested it; so I hesitated to claim we supported it. Especially when I had heard people were having problems with it.

Thanks again,
dbethers

0
Login to vote
Admin's picture

Thanks for the heads up, Bo.

The paths should be correct now.

JM

0
Login to vote
nathandol's picture

Hi All,

I am testing out the SVS Login Hook at the moment before I get stuck into testing the Altiris/Symantec/AppStream solution of SVS Pro. I haven't yet tested out how the login hook works on a laptop when the laptop is disconnected from the network and AD, but so far I so no real advantages with using SVS Pro for streaming apps. We are running Altiris Client Management suite and are able to deploy svs packages via NS/DS, the login hook then takes control of which vsa's to load on login.

Am I missing something obvious here guys?

Thanks for your help in advance....great site by the way

Nathandol

0
Login to vote
Scott Jones's picture

The logon hook functionality is about 2% of the SVS Pro streaming system functionality...

With SVS Pro streaming, you get multiple delivery options (pre-populate icons/apps, stream on demand only, cache all/part/nothing, stream from self-service Web portal, including over the Internet to unmanaged machines, etc., etc.), all centrally managed. You also get a delivery infrastructure that can be tiered, with automatic replication of the software store and delegated administration. Not to mention license management and versioning control. And you can use all of this with traditional MSI packages as well as with VSPs.

We intended the logon hook to be used in standard images on blade PCs, Ardence/Xen Desktop type systems and VDI/VDI-like systems, where there would only be one place to go to manage the config and therefore less of a need for scalable centralized management. Also, less of a concern about bandwidth consumption. But it sounds like you are using it in
a distributed environment, on fat clients; and its meeting your needs so far. I would encourage you to write up as much detail as you can about how and why you are using the logon hook and submit an article to the Juice!

Scott Jones
Product Manager
Symantec

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

0
Login to vote
Scott Jones's picture

In fact, to anyone using the SVS Logon Hook in any environment other than blades, streamed OS or virtualized OS -- Please let us know now!

SVS Pro has become our solution of choice (and customers' and partners' solution of choice) for these environments, both because it's more feature rich and because it allows a single point of administration across client types. (So with one set of packages and policies, a given user can get their apps, for example, on either a blade PC or a laptop.) So we've been thinking about reverting the Logon Hook back to unsupported status, as a Juice tool. If that's the wrong thing for Symantec to do, please explain why so we can make the right decision. Thanks!

Scott Jones
Product Manager
Symantec

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

0
Login to vote
nathandol's picture

Thanks for the quick feedback. If the logon hook only supports 2% functionality then I am definitely going to investigate SVS Pro at our site. I can't tell you how much I like this little SVS Logon Hook tool bundled with SVS and Client Management Suite because as the Company stand now, we could implement this as a solution to our apps needs (minimum requirements) and DR requirements.

I will be investigating SVS Pro to weigh up the Pro's and Con's of each solution so please keep me posted on the support status of SVS Logon Hook as this will no doubt have an impact on the Companies decision down the track.

Cheers.

PS The Logon Hook did not like the laptop being disconnected from the network and AD. It did not load any of the SVS Apps even when logging in with a local account that was part of a local group that had been added to auto import and activate an SVS. Plug the laptop back into the network and the very same local user received the SVS App. I used the default %WINDIR%\SYSTEM32\file.xml method for this and no other entries in the Regedit key.

0
Login to vote
ASTon's picture

Negative: Please leave it under support as-is.

I'll give you a recent example why;
We currently are working with a customer who is seriously considering to implement SVS using SVS Logon Hook to cover the policies for end-users.

Reason;
This client is bound to a service contract that does not allow them to implement another tool (e.g. CMS / SVS PRO!) other then covered by the contract. All systems management & software distribution has to go through Some Management Solution.

SVS / VSA packages on the other hand can and may be used because it can be distributed conform contract conditions & on the other hand can be controlled/managed via SVS Logon Hook.

For Symantec this means you have a solution which can still be used within these kinds of environments whereas SVS PRO would not be accepted!

Something to discuss/think about I'd say?! If you have another view then feel free to comment.

Regardz,

ASTon.

0
Login to vote
jfinnis20's picture

I manage a school district network. We have about 1100 client systems with SVS and Logon Hook. I use Logon Hook to reset each layer on logout. With the layers tweaked so all nassary settings are on the readonly layer we have no need to keep changes. I'd love for there to be an easier way to make layers readonly since the current solution slows logoff, has a central point of failure, and the XML file has to include every layer a system might have.

0
Login to vote