Software Deployment

Alright, it let me add the mst file fine this time, but it's still not installing properly via group policy. Below is the error I get in the application log (which is the same one I imagine we've been talking about). I'm still posting in this forum because this is specifically about the Cisco VPN client, just that one post was regarding group policy only.

Product: Cisco Systems VPN Client 5.0.02.0090 -- Error 28006: Trying to install the VPN Client from a network drive momentarily disconnects network drives and can cause the installation to fail. Copy the installation files to a local drive and restart the install.

What an absolute twit I am, in not spotting the connection (sic). Of course a VPN client can't be installed over a network connection! I wouldn't mind but I was part of a lengthy thread on this subject very recently.

It hink you'll need to deploy this by some other means. Thinking about it, it would make sense to a local, admin-level install since, by definition, remote boxes won't have access to the network - why else would they need a VPN client? - so they need to be set up first. That provides the opportunity to perform the install "in the shop", either from removable media or by copying the package locally and running it from there.

I thought that was what this posting was about, trying to get Cisco VPN to install automatically, probrably from a network location.

When I drop that line and save the msi, it lets me install from a network location by manually double clicking the msi file located at the same place (on the network). Why would it let me install by double clicking from a network location, but not via group policy from a network location? I am also able to install using the transform command line you suggested from a network location, but unable to push out the msi and mst file via group policy. Command line used below. Again I ask myself, why does it let me install from a network location manually, but not via group policy?

I realize this wont install for remote computers until they boot while on the network. That's fine. As long as its eventually installed, I have that much less work to do on new machines as well, and I can tell users without it to just reboot while connected here instead of them needing to wait for me to install for them, ect.

msiexec /i "\\srv-file\Z\Software\Internet and Networking\Cisco VPN 5.x Client\vpnclient_setup.msi" transforms=\\srv-file\Z\Software\Internet and Networking\Cisco VPN 5.x Client\vpnclient_wonetworkcheck.mst

Thanks for sticking through this.

I'm afraid I don't know enough about the nuts and bolts of GP in a network sense to make a diagnosis but I imagine it's because of some difference in the way that WI caches GP installations.

Alright, thanks for trying.

Anyone else have any idea?

I think it is possible to use WPKG instead (which can be called/initiated by GPO): http://wpkg.org/Cisco_VPN

ORIGINAL: revizor

I did experiment with disabling reboot. The problem is that the software will not establish a tunnel unless you do reboot, so I decided to leave reboot alone...


Where and how do I turn of the reboot? I want so set the reboot in my deployment tool instead of in the software package its self. I have version 5.0.03.0530 of Cisco VPN Client.

Thanks in advanced!

ORIGINAL: daileyks

Below is KB article from the Cisco web site. I haven't tried it yet though.

CSCse00525 Bug Details

unable to install vpn client via Active Directory

Symptom:

When using Active Directory and Group Policy to automate the VPN client install on domain computers, the install fails. An error is logged in the event log on the client computer:

Product: Cisco Systems VPN Client 4.8.01.0300 - Error 28006: Trying to install the VPN Client from a network drive momentarily disconnects network drives and can cause the installation to fail. Copy the installation files to a local drive and restart the install.

Conditions:

Windows software deployment of the VPN client MSI to an active directory client via a Group Policy Object configured for the Computer scope.

Workaround:

Repackage the MSI package using AdminStudio from InstallShield or Package Studio from WISE.

General guidelines for repackaging:

1. Embed vpnclient_setup.msi into your custom MSI package.
2. Tell the repackaged MSI to download then execute the vpnclient_setup.msi from local machine.


You'd think if that was nessesary in order to deploy it, they would've made the msi that way to begin with. Isn't that half the point of msi files? To deploy them?

Is there some way to do this using Orca? I don't have any of those package programs you need to pay for.

I noticed the quoted text specifically says this is nessesary when "configured for the Computer scope". Does that mean it installs fine when I deploy it using the User scope? I tried this and it didn't work either.

The Cisco VPN client installation replaces the TCP/IP stack and therefore looses drops the network "support".
That is why you need to wrap it and install it from a local source.

HI All,

I did as they say in the KB for this package:

Open the MSI with ORCA
Go to the CustomAction table
Delete this two rows:
CsCaDll_GetInstallDriveType - DELETE ROW
CsCaDll_GetInstallDriveType1 - DELETE ROW

Save and deploy. Works fine.

BUT. I get a real ugly message box when the installation is finished that says that you need to restart your system in order to use VPN. Restart now? Yes or No.
I dont want that screen to pop up at all. I want to set the restart in my deployment tool instead so it restarts automaticly....
How do I disable the reboot?

Thanks!

- Firstly, as an AppDeploy 'veteran', you must surely have got the message which we continuously pump out here:

DO NOT EDIT VENDOR-SUPPLIED MSIs.

Use a transform.

- Secondly, is our other message:

DO SOME RESEARCH FIRST.

- Digest the contents of MSDN for properties 'REBOOT', 'REBOOTPROMPT' and the Custom Action 'ForceReboot'. It is entirely possible, though, that the vendor uses a function in a custom DLL, in which case you'll need to track it down and 'disable' it. You can do that by adding an impossible-to-meet condition (say, 0=1) on its execution.

Use the /norestart switch after vpnclient_setup.exe

install_folder\vpnclient_setup.exe /norestart

Go to the CustomAction table
Delete this two rows:
CsCaDll_GetInstallDriveType - DELETE ROW
CsCaDll_GetInstallDriveType1 - DELETE ROW


That made my deployement work on v 5.0.02.0090. Thanks. (using mst though instead, of course).

aXz, can't you just backup the vendor supplied msi before editing it? Or is this more of a keep track of what's been done to the vendor supplied msi type of thing. Seems like if you just create another copy called original, you could always go back.

As for restart, I think I'll let the user choose that. Why would you want to auto restart anyway? In most cases they wont need it after first boot and you're just making them spend more time waiting for the computer to boot. At least they can't say they weren't warned that it wont work until after reboot.

As for restart, I think I'll let the user choose that. Why would you want to auto restart anyway? In most cases they wont need it after first boot and you're just making them spend more time waiting for the computer to boot.

Correct, in most cases they won't. Consider this scenario:
[Helpdesk]: Good morning, how can I help you?
[User]: I need to be able to connect to so-and-so system. It's urgent.
[Helpdesk]: Just one second... Ok, I just made a change... Try in 30 minutes - you should be able to connect...
[User]: 30 minutes? I prefer it ASAP.
... 10 ... 20 ... 30 ... 35 minutes later ...
[Helpdesk]: Good morning. How can I help you?
[User]: I called you this morning, and you told me my connection to such-and-such would work by now. Well, it doesn't...[:@]
[Helpdesk]: Ummm, let me send someone over to have a look at your computer... The technician is on his way...
[User]: You guys can't ever get things right the first time... Have a nice day.[:@]

I think performing a reboot when reboot is necessary is a good idea in general. Imagine you are a software company. You put your eval version on the web for users to download it. User downloads and installs it, but the software won't work until (s)he reboots. Chances are the user will give up on trying to demo your great application, and may uninstall it all together before the first reboot...

And, last, but not least, from my experience the concept of "reboot" has different meanings to different sets of users: some "reboot" by closing out of their applications and logging off and logging back in, some - by closing the lids of their laptops, some would reboot in the middle of installation, and if you ask VDI and thin devices admins, you may discover other intricacies of an allegedly simple reboot operation.

ORIGINAL: Waldo120


Go to the CustomAction table
Delete this two rows:
CsCaDll_GetInstallDriveType - DELETE ROW
CsCaDll_GetInstallDriveType1 - DELETE ROW


That made my deployement work on v 5.0.02.0090. Thanks. (using mst though instead, of course).

aXz, can't you just backup the vendor supplied msi before editing it? Or is this more of a keep track of what's been done to the vendor supplied msi type of thing. Seems like if you just create another copy called original, you could always go back.

As for restart, I think I'll let the user choose that. Why would you want to auto restart anyway? In most cases they wont need it after first boot and you're just making them spend more time waiting for the computer to boot. At least they can't say they weren't warned that it wont work until after reboot.


Yes I have a Backup of the MSI. Maby I should go back to that and do an MST.

Regarding the restart. If we set restart after installation in our software delivery tool a scrren will pop up and the user get to choose if they want to reboot now OR they can procrastinate the reboot up to 6 times I think.
And if they choose to procrastinate the reboot the 6 times at one time I think the time is 6 hours until the reboot will be done. So its pretty flexible for them anyway.

Hi John,
it's a little late for answer. But for other people with the same problem, here a solution:
The showstopper action is "CsCaErr_GetInstallDriveType1" in the InstallExecuteSequence table.
Change its condition to one, that gets never true.
This problem with the network adapter turned down during this installation, will not occur, because the file copy action is finished, when the network is turned off.

But be cautious: This package can't be upgraded! And this will be a real pain with GPO install. It needs a complete uninstall with a reboot, before you can install a newer version.

Regards, Nick

I have a shortcut solution for this problem: disable check for network installation. Don't remember the exact name of the custom action, but once you comment it out, Cisco VPN client installs fine. There is a disconnect during the installation, but it does not disrupt the client installation. The 3.x => 4.6 upgrade, however, involves manual removal of the old client.

Thanks! I found it and that fixed my particular issue. I'm going to post in the KB for others, and will give you credit for the solution.

You make me flush like a tomato [:D]

i used the custom actions to allow group policy install of Cisco VPN client which works great thanks (no problems with network error). However now after the software installs, it reboots before the logon box appears. Is there another custom action to stop the reboot? I cannot find it. Thanks very much.

I did experiment with disabling reboot. The problem is that the software will not establish a tunnel unless you do reboot, so I decided to leave reboot alone...

We built a script that copies the files locally. The first thing the script does is copy itself and the needed MSIs (Cisco VPN, Ipass, etc) to a local folder. Then we have the script kick the local copy of itself off and finish. AD will run scripts and this worked fine for us.

Hi There,

I was wondering if you could post that KB. I'd love to see it.

Thx!

Below is KB article from the Cisco web site. I haven't tried it yet though.

CSCse00525 Bug Details





unable to install vpn client via Active Directory

Symptom:

When using Active Directory and Group Policy to automate the VPN client install on domain computers, the install fails. An error is logged in the event log on the client computer:

Product: Cisco Systems VPN Client 4.8.01.0300 - Error 28006: Trying to install the VPN Client from a network drive momentarily disconnects network drives and can cause the installation to fail. Copy the installation files to a local drive and restart the install.

Conditions:

Windows software deployment of the VPN client MSI to an active directory client via a Group Policy Object configured for the Computer scope.

Workaround:

Repackage the MSI package using AdminStudio from InstallShield or Package Studio from WISE.

General guidelines for repackaging:

1. Embed vpnclient_setup.msi into your custom MSI package.
2. Tell the repackaged MSI to download then execute the vpnclient_setup.msi from local machine.

can you tell me where the kb article is or what custom action it is?

revizor or woodyard, what file would I "comment out" this check for network install from? I opened everything but exe and msi with notepad and don't see anything like that.

I have version 5.0.00.0340

Deploying Cisco VPN client via Active Directory

Can anyone please provide a proper solution for the problem being discussed above.
I am too facing the same problem and not able to get through it.

What is the Custom action? and also how to implement this Custom action and also where to implement??

I am a developer in .Net technologies and forced to do this in which i dont have any idea..
Any help would be greatly appreciated.

Thanx

From what I see you need to look for CsProp_GetDriveType (in ver 4.8 of client)

From what I see you need to look for CsProp_GetDriveType (in ver 4.8 of client)

Anyone know how to do this in v5?

I turned off the 'check for network drive'.
Drop CsCaErr_GetInstallDriveType from InstallUISequence.

ok, maybe I'm a noob to this particular issue, but how do you go about doing that? I've opened all the install files I have with notepad and can't find any of those variables.

Is this a way to deploy it using group policy or are we still talking via the script?

I hate to do this, but I'm going to give a concise answer instead of a long how-to. What you want to do is normal and you are in a good place for information. Unfortunately you are about to enter the trial & error, learn the tools phase.

Get ORCA from Microsoft. It's a free download in one of the SDKs. ORCA opens msi files and shows you the contents. Don't use Notepad.

MSIs are full of little tables. The little tables have rows, and the rows can be instructions to msiexec (the Windows installer), or information about the files to install, stuff like that. The other applications you read about, such as InstallAware and InstallShield, are also msi editors but they are commercial applications. Easier to use, but cost money. And, in our case, have more features than we want.

Start ORCA, open the vpnclient msi. You will see a list of tables on the left. When you select a table, you will see a list of rows on the right. ORCA displays this stuff, and allows you to edit the rows, and add or delete rows. BUT the best practice is to 'generate a transform' to contain your edits. The transform is like a patch that you apply to the msi.

Create a transform. On the list of tables, look for InstallUISequence. Select it. From the list of rows, look for CsCaErr_GetInstallDriveType. Right click it, and select 'drop row'. From the transform menu, select "generate transform" (IIRC).

You just told the InstallUISequence 'script' not to run the 'CsCaErr_GetInstallDriveType' action. We are guessing from its name, that it checks the drive type for network or local. If network, CsCaErr_GetInstallDriveType halts InstallUISequence. So we just remove that action. (But recall we are inferring that from the name of the table and row. If this doesn't work, you undo your work and browse the msi for something else with a likely name. Look at Properites, CustomAction, InstallUISequence, AdminUISequence).

To test your transform, go to a command prompt and enter
msiexec /i <msi_name.msi> transforms=<transform_name.mst>

Wow, I wimpered a little bit when I read your post, but all in all that was easy.

I guess I spoke too soon. By dropping CsCaErr_GetInstallDriveType from InstallUISequence I am now able to install manually (double clicking the msi) without copying the install files to a local disk, but when I add it to group policy to install I still get the same error in my application event log.

Did you also add the transform you created with the CA removed, using the 'Modifications' tab? If not, the GP won't know about the transform, won't apply it and the CA will therefore execute.

Instead of creating a transform I just backed up the msi file and editing the original I have on my network, and saved the changes. I was under the impression that to use a transform I would have to run a script to run "msiexec /i <msi_name.msi> transforms=<transform_name.mst>" so instead I edited the msi itself, saved it, and added it to my software list.

Are you saying that when it comes to deploying via group policy you HAVE to use transforms, and any edits to an msi file directly are ignored by group policy?

Are you saying that when it comes to deploying via group policy you HAVE to use transforms, and any edits to an msi file directly are ignored by group policy?Not at all, no. It's simply that as soon as you edit a vendor-supplied MSI, you can open up a whole can of worms. It is generally accepted that it is A Bad Thing and that changes should be applied via transforms. As I mentioned, GP allows you to add as many transforms as you want.

ok, I recovered my original msi file, created an mst file with that line dropped, then added the msi file to the group policy. Then went to properties, clicked on the modifications tab, and all buttons are greyed out so I can't add my mst file.

I tried the same thing under User Configuration rather then Computer Configuration and got the same problem.

That's because you clicked 'OK' after adding the MSI, right? And then went back to add the MST, right? Well, GP is pretty dumb in not allowing that. You have to do both steps at the same time. You can work around it without having to create another policy by removing the MSI and adding it straight back. This time, add your MST before clicking 'OK'. OK? :)

EDIT:
BTW, there is a separate 'Group Policy' forum http://www.appdeploy.com/messageboards/tt.asp?forumid=10 which is really where you ought to have posted. Remember for next time, maybe...