So I came up with this idea (and I don't even think it's a good idea, but all we can come up with) in our environment to have a google chrome .msi package sit on file share server. We have configured over 500 virtual machines, so far, to install this package upon logon. Now i'm starting to experience a slowdown of the installs, as well as other slowdowns with programs used on the same server. The idea being when chrome needs to be updated constantly, we update one file, instead of 500 machines.

It's a 2003 server, a virtual machine as well, with a 10gb network link. All the clients have 10gb as well, as they are all inside the vmware environment. The network usually doesn't go over 1% on the server at peak morning times and doesn't drop to 0% until middle morning. The CPU and RAM usage is nearly idle as well.

The installs use to take around 40-50 seconds when I first deployed it, now it can go over 10 minutes in the mornings. The client machine is idle, basically waiting for the package to download I assume? But not sure.

I'm curious as to any limitations I might be running into using one file to install on 500+ machines a day. The file share is set to the "maximum" whatever that number may be. Any ideas would be most appreciated! At this point I might try to put this file on a 2012 server, or attempt to switch the script to a startup script instead of a logon script to help alleviate the load in the morning. But still won't have an answer to my root bottleneck issue if i do.

And I'm sorry too if this answer could be found somewhere already; I just can't find anything in my searches.

Darin

Hi Darin,

As you mentioned it is a "logon script", it seems that you are not using software deployment to do this job. 

What's exactly the script do with the MSI file?

If it is just for installing it, does that mean every time user logged on, the MSI file will be performed one time regardless it is already installed or not? 

Instead please test to use Group Policy to do this deployment job instead. Please refer to the steps of "Create a distribution point", "Create a Group Policy Object" and "Assign a package".

Thanks for the reply!

Yeah, we tried doing it thru GP first, but had very unreliable results. I think out of 10 reboots, the package only installed 4 times.

We have a unique VMware environment in which all machines "refresh" themselves upon a reboot. This means that anything installed, including this Google chrome package, is wiped upon a reboot. Same goes with these GP settings, which i think is why it's so unreliable.

We want to do chrome this way, so that when we have to update it, we can update it for the whole college (over 2200 machines) in one simple change of the .msi file on the file share. Then the next reboot they do, which is typically over night, they have the new version automatically. This saves us from having to add the new version to up to 51 different templates, and pushing the updates to their machines in that method.

For now, to speed things up, it appears to work better if my script copies the .msi package to the root of C: first, then execute it from there. For some reason, executing it straight from the server causes it to take 7-10 minutes to install at peak times in the morning, versus 45-60 seconds locally.

Also, the slowdown appears to be affecting other network shares on the same server, hence my need to fix this situation for both reasons.

• Edited by darin311 15 hours 58 minutes ago typos

1. Google support may help.

2. You may influence the situation by changing parameters in msiexec

3. Inspect log files

4. Inspect Performance Monitor. Use Sysinternal Process Monitor for troubleshooting.

5. Group computers into groups and install in groups and in different time.

6. Consider copy to local and execute remoteley (psexec)

7. There are alternatives, namely Scheduled task at logon etc

M.