Using a Variable for Delivering Applications to Workstations
Novell Cool Solutions: Trench
By Julian Greenwood
|
Digg This -
Slashdot This
Posted: 25 Nov 2002 |
Here is a very neat solution to deploying applications to workstations in a large environment.
Situation
- You have multiple sites that hold users.
- Each site maps users to different application servers.
- You want to create one AO for the whole enterprise.
- You want to use UNC pathing in the AO.
As you can see UNC pathing would mean that each AO would have to be modified with the server name in the UNC path.
Solution
When you setup the workstation import service, have the service run on your applications servers at each site. Have this put in the DNS for each site.
Now you can use this in your AO's for workstations.
\\zenwsimport\apps\win\
This will then pickup the server that is running the service and, hey presto, you have one application that works for all sites.
You can test this just by doing a ping of the zenwsimport service and see what comes back.
(Note: you will still have to give rights to the server to the workstations.)
Other Ideas
Ruud Hanegraaf
We have a similar situation, with different sites throughout the country. Many of our employees are roaming users and log in at varying locations. We have a single replicated ZEN container containing all application objects and other ZEN stuff. For the sake of speed and simplicity we made all objects location independent - one size fits all - always using the nearest file server. What we did was this.
We created a profile login script in our ZEN container, which we included in all our container login scripts. This script checks from which physical location the user is logging in. Based on the result a variable is set containing the local file server and another one with the SYS:\PUBLIC of the local server.
REM Check IP address REM (...) REM 10.173.0.0 - 10.173.255.255 IF NETWORK_ADDRESS >= "0AAD0000" AND NETWORK_ADDRESS <= "0AADFFFF" THEN GOTO UTRECHT END REM 135.8.0.0 - 135.8.255.255 IF NETWORK_ADDRESS >= "87080000" AND NETWORK_ADDRESS <= "8708FFFF" THEN GOTO AMSTERDAM END (...) GOTO ENDINCLUDE REM Locations REM AMSTERDAM: DOS SET LOCALSERVER = "FSWPA01" DOS SET PUBLOCAL = "\\\FSWPA01\SYS\PUBLIC" (...) GOTO ENDINCLUDE UTRECHT: DOS SET LOCALSERVER = "FSWPA08" DOS SET PUBLOCAL = "\\\FSWPA08\SYS\PUBLIC" (...) GOTO ENDINCLUDE (...) ENDINCLUDE:
Note: The network address contains the hexadecimal representation of the workstation's IP address:
135.8.10.35 -> 135 = 87, 8 = 08, 10 = 0A, 35 = 23 -> 87080A23
These variables are then used in all kinds of procedures and objects.
In batch files:
REGEDIT -S %PUBLOCAL%\CONFIG\VPN\VPN.REG XCOPY %PUBLOCAL%\CONFIG\DEFAULT\*.* P:\ /E/D > NUL
In application objects for application files (or environment variables or whatever):
%PUBLOCAL%\CONFIG\SAP\Sap*.ini -> C:\Winnt\Sap*.ini
Some applications are not installed on every server. If a user is logged in on a site which is not his home site, but which does have one of those applications installed, we use the following pre-launch script to make sure he uses the local application and not the one at the other end of the WAN link. This script uses the EXIST.EXE utility which can be found in the Cool Tools.
SET TSDAPPS = "\\\%<LOCALSERVER>\DATA\APPS" #%<PUBLOCAL>\UTILS\EXIST.EXE %<TSDAPPS>\TSD IF "%ERROR_LEVEL" <> "0" THEN SET TSDAPPS = "\\\%<SERVER>\DATA\APPS" END
Note: SERVER is a variable set in the container login script containing the default file server of the user's container.
Then in the application objects we specify %TSDAPPS%\TSD\KML.EXE as the executable (for example) and %TSDAPPS%\TSD as work directory, etc.
It looks complicated, but it is very flexible.
P.S. We still use NW 5.0 and ZEN 2.0, so I don't know if higher versions provide simpler solutions.
If you have any questions you may contact Ruud at r.hanegraaf@laurus.nl
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com