Running an App Object as Secure or Unsecure System User on Windows XP
Novell Cool Solutions: Tip
By Rich Stevenson
Digg This -
Updated: 10 Feb 2006
PROBLEM: We're all familiar with the problem that exists when running an application object as Secure or Unsecure System User on a Windows XP box. With Windows NT/2000 every process shared the same drive mappings but in XP the system does not have access to those mappings. The work-around is to use UNC pathing instead of a mapped drive. This works well but can also cause additional work for the administrator if the application exists in multiple locations, i.e. satellite offices across the WAN. The problem is, if you have to use UNC paths, you'll need to create a separate application object with the respective UNC path for each office.
SOLUTION: Instead of creating an application object for each location, you can set and use an environment variable that will pass the name of the server your user is logged into. Here's what you need to do:
In your login script, add the following line:
This line will create an environment variable in Windows using the name of the server the user has logged into. You can verify this from a Command prompt by typing 'SET' on the workstation.
Now, in your application object use the new variable to build the path to your application like this:
So if your server name is FS1, then this line translates to
when the application is run.
You can also use the new variable for MSI installs through ZENworks. Just make sure the path to the MST file also uses the variable. If you do use this technique for an MSI, you will receive an error in ConsoleOne when you view the properties of the object. The error reported is, "Database could not be opened. MSI file could not be found." Click the Close button and the properties page will be displayed. The error occurs because ConsoleOne doesn't use the variable when it's checking to see if the MSI file exists. But this doesn't affect the user when the application is run.
You now have one application for all of your locations that automatically runs from whichever server the user is logged in to.
One thing to keep in mind is that this solution will only work if your application files exists on the same server that the user logs into.
If you have any questions you may contact Rich at firstname.lastname@example.org
Actually we have been doing this already without adding a set statement and using the default variable %FILESERVER% or %FILE_SERVER%. You can use the same variable (with just the preceding %) in the login script to run an executable also. I experimented with your steps and when I tried to use the %SERVER% variable in the login script it errors out. I was just wondering what the advantage would be of following this tip rather than using the default variable which works in both NAL apps and the login script.
Thanks Rich, your article is very cool. However, one simple improvement could be, if you use the variable 'zenwsimport' instead of the File_Server variable to make sure that the app object on every users site connects to the appropriate ZENworks server. (This is, in our case, better than the file server.)
If you have any questions you may contact Roland at Roland.Pfenninger@fd.zg.ch
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com