timallen
Well Known Member
Hi Everyone,
I've just added one more line to my client installation checklist:
_ Check connectivity to the deployment server prior to accepting a package at the fat client.
I found this out the hard way. At our very security-conscious client's site, we had to install some update packages that I had previously distributed to some workstations. I don't have a user with enough horsepower to modify the registry (yup, I *am* the CNC), so as usual I had to have a tech support guy along to sign me into the machines with the local administrative user.
The other cool thing about this site is that not everyone has access to the deployment server's shared B7333 directory. Actually, I can understand this one pretty well-- having read-write access for "everyone" to a big directory on a server is asking for trouble.
The problem here is that the local administrator for each machine doesn't have access to the Deployment Server, either.
So I started up OneWorld on each machine, accepted the update package waiting for me, and got an error saying that OneWorld couldn't find setup.exe. I thought, that's odd, it's right there in the B7 directory on the local machine. Mistake. The setup.exe they were looking for was the one on the Deployment Server.
So when the error message asked if I wanted to try to find setup.exe myself, I said yes. I steered over to C:\B7\setup.exe. The installation of the package launched and finished just fine. However, when I tried to enter OneWorld, I got the little login screen for the System B7333 data source, again and again. I had fried the client installation.
Fortunately, I had a partial package made up previously, so I deinstalled, mapped a drive to B7333 on the Deployment Server, did the installation, and distributed the package to the workstation again. This time the package installation went without a problem, because I had mapped the drive.
I could have avoided all of this by simply trying to open \\DEPLOYMENT\B7333. When it asked me for a user and password, I would have been able to connect and thus have authorization to get at the package.
Hope this saves someone some grief.
I've just added one more line to my client installation checklist:
_ Check connectivity to the deployment server prior to accepting a package at the fat client.
I found this out the hard way. At our very security-conscious client's site, we had to install some update packages that I had previously distributed to some workstations. I don't have a user with enough horsepower to modify the registry (yup, I *am* the CNC), so as usual I had to have a tech support guy along to sign me into the machines with the local administrative user.
The other cool thing about this site is that not everyone has access to the deployment server's shared B7333 directory. Actually, I can understand this one pretty well-- having read-write access for "everyone" to a big directory on a server is asking for trouble.
The problem here is that the local administrator for each machine doesn't have access to the Deployment Server, either.
So I started up OneWorld on each machine, accepted the update package waiting for me, and got an error saying that OneWorld couldn't find setup.exe. I thought, that's odd, it's right there in the B7 directory on the local machine. Mistake. The setup.exe they were looking for was the one on the Deployment Server.
So when the error message asked if I wanted to try to find setup.exe myself, I said yes. I steered over to C:\B7\setup.exe. The installation of the package launched and finished just fine. However, when I tried to enter OneWorld, I got the little login screen for the System B7333 data source, again and again. I had fried the client installation.
Fortunately, I had a partial package made up previously, so I deinstalled, mapped a drive to B7333 on the Deployment Server, did the installation, and distributed the package to the workstation again. This time the package installation went without a problem, because I had mapped the drive.
I could have avoided all of this by simply trying to open \\DEPLOYMENT\B7333. When it asked me for a user and password, I would have been able to connect and thus have authorization to get at the package.
Hope this saves someone some grief.
