Setting the SVS User Logon Hook's Registry Flags
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.
- Login or register to post comments
- 4412 reads
- Printer-friendly version


















Registry Path Corrections
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
Re: Registry Path Corrections
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
Fixed
Thanks for the heads up, Bo.
The paths should be correct now.
JM
SVS Login Hook VS Appstream solution
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
Streaming v. Logon Hook
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
Using the SVS Logon Hook? Let us know!
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
Thanks for the quick
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.
Customers bound to service contracts
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.