Client Security Upgrade from v9 to v10 fails
I expect I'm going to be told to update our PM server but I didn't want to do this just yet as I gather there are a number of major differences so for the time being, I wanted to update the last of our v9.x clients to v10.01.
Our PM server is v10.20 and we are running CS9.01, CS9.11, CS9.20 & CS9.32.
I tried updating all the clients on CS9.01 via the "Installation" tab in the PM by clicking the "Upgrade" action below the "Installed Products Summary" section and all the clients failed to install v10.01 properly.
First I targeted v9.01 and then v9.20, same result. I also tried XP and Win 7 clients - both fail.
What happens is that the v10 client installs but after the PC has restarted, CS starts misbehaving and the PC is almost unusable. On further investigation, it appears that launching the CS console, all the settings in "Automatic updates", "Central Management", etc aren't populated and therefore CS doesn't know where to communicate and therefore goes into some sort of discovery mode causing the PC to lock up!
However deploying CS from the console via "Push Install to Windows Hosts" works fine!
I really wanted to use the upgrade by client feature as it's a great way to version update and has always worked for me in the past with previous versions of CS and the PM.
Anyone have any ideas or aware of any issues regarding this process?
There could be several reasons for this issue. Unfortunately, it's impossible to find the root without fsdiag report form affected machine. For example, it could depend on the hotfixes installed/not installed on your client machines.
Note that "Upgrade" scenario uses the binaries form currently installed (9.01 in your case) version of the product, while "Push install" uses the binaries from pushing product (10.01 in your case).
Also, we can't do much with the issues happening with the old versions 9.01 - 9.20, as they are not supported already.
You can find the information about supported products/versions here:
Thank you very much for this as that makes sense.
What I'll do is try to find a machine which is exhibiting the behavior and run an FSDiag and can I PM it to you?
It would be useful to know what has gone wrong, in case it's a PM10 problem. I have 62x v9.01 machines to update and then I have 405x v9.20 and 20x v9.32 machines left to version up to 10.01.
I would hope that it won't hapen to v9.20 and v9.32 but I'll have to test this before I deploy an upgrade to avoid big problems on my network.
I realise that v9.x is going out of suport which is why I've not logged this but I'd apreciate some guidance on gettting rid of all my v9 clients.
I did explain that in my original post.
I also checked the product lifecycles and CS10.01 & CS11.x have almost the same EOL dates being 2016. There are also significant differences between those products.
When F-S release an update for server security, that will probably require another PM update therefore I'll wait until then to update our PM.
We already have a massive undertaking to move from XP to Win7 by April so I don't want to create more work and uncertainties by adding a new PM plus a new CS version just yet!
We have just under 1000 machines so this is a massive undertaking, which we've already started so we expect to reach this goal by the latest May this year.
Hello Vad, sorry about the delay but we've had so much work going on and I had a number of machines which needed correcting manually, plus trying to upgrade groups of machines at the time, I've had little time to collect an FSDiag but I've done so now and put a suport call in yesterday with an FSDiag.
The SR ID is: 1-692037494]
I'm trying to get the rest of my machines updated to v10 as quickly as possible so any help would be apprciated.
We can see a set of issues in the fsdiag. Unfortunately, it's still hard to find the clue, what is the initial reason of such behavior.
Fsorspclient service is disabled. Did you do it manually after the upgrade? This could be one of the reasons.
Firewall daemon and NRB services are stopped. FSMA is not fully functional.
Further investigation will require collecting debug logs from failing modules. If you want us to continue investigations, please contact support.
I have contacted support but I'm still waiting for someone to contact me through the official channel. However, as I seem to be geting yourself on occasions who has been very helpful and knowledgable, I'm more than happy to pursue this issue via the forum as any info found may also help others with this migration.
Basically, we have been diabling the ORSP client via a Group Policy setting which was a recommondation by the old UK support engineer who has left the company now.
The reason for this was becasue with almost 1000 clients on the network at the time, we were getting our firewall hammered by all our clients as the ORSP client was trying to do cloud lookups and at the time, our old firewall couldn't cope as it was spiking the CPU. Obviously we've since taken those rubbish Checkpoint appliances away and gone to another vendor and that was one of the best decisions we've ever made!
Anyway, as at the time of v9 release or was v8, I can't rememeber, there was no provision in the F-S PM to disable this service to avoid our firewall from geting loads of hits to your lookup service so that's why we still have the ORSP client disabled.
I've requested by an RFE that this behavior be looked into as it causes lots of traffic emanating externally when I think this info could be cached on the PM or something to avoid such issues.
I'm hapy to PM you debugging logs, just let me know which one's you need.
Please bear in mind though that the client machine which that FSDiag comes from, has had that malfunctioning install, removed, machine rebooted and a new push install of v10.01 installed and it's now running without problem.
If the debug logs haven't been overwritten, I can go and retreave them.
Thank you again Vad, Rick.
I would recommend to enable the ORSP client service before the upgrade. We didn't ever test the scenarios when any changes were made in the original services configuration.
After the upgrade you can disable it again.
Debug logs require debug binaries, which support can provide for you. We'll need FSMA, Firewall and NRB debug logs.
The scenario could be:
- start upgrade.
- when the reboot is requested, replace original binaries by debug versions and make needed changes in registry for collecting debug logs.
- if the issue is reproduced, collect fsdiag + debug logs, and send this staff to support.
I see the following error message in FSPM 11.10, but do not know its significance? The target workstation has a single HDD with two NTFS partitions and there is least 7-10 GB free space on each one!
"Upgrading FSCS from 10.00 to 11.50 on host XYZ failed: the F-Secure installation process could not unpack the installation package. There is not enough free space on the hard disk."
Thanks in advance, Yours Sincerely:
Tamas Feher, Hungary.
Wow Vad, that's quite involved.
I'm not sure I'll have all that time to perform all those changes.
However, note that our install contains only 4 of all the modules for CS as we provide the other elements of security using other methods to reduce possible threat vectors.
What I will try though is enabling the ORSP client to see whether that resolves the issue and I can probabaly do that this afternoon.
I'll post back shortly.
> I would recommend to enable the ORSP client service before the upgrade.
Does it make sense to struggle with a problemful version update? Why not use the "SideGrade.jar" tool, which can be distributed to the clients via FSPM and thus, remotely wipe them clear of any FSAV?
( The currently available SideGrade package is very old, however, as it dates from late 2011. I'm not sure if it could handle FSCS v9.xx removal properly? I think F-Secure Corp. should release an upgraded package, see:
Following SideGrade, the clients would be re-installed with the F-Secure workstation protection software from scratch, using either FSPM's push method or the re-export of JAR file in the form of a pre-configured MSI package, which can then be distributed via AD GPO.
This method is probably more reliable than trying to force an improperly working client to upgrade itself?
Well the client is working properly but it fails after the upgrade.
If a software vendor provide a mechanism to update their software and it doesn't work, it's not the customer's fault as they're only using the tools given.
As it appears that pushing out a new binary works as it should, of course using an MSI atached to a GPO is a good alternative.
However to avoid the whole organisation having a delay during log-in, I'd have to filter the GPO on group but it is an option which would work reasonably well but still not as good as using the upgrade provision in the console.
Thanks for the suggestion etomcat.
It looks like we've been chasing our tails with this one as my experiences installing this appear to be well documented in the release notes and I quote;
Policies are not received immediately after reboot
In some cases, the installed client may not receive policies immediately after the reboot. Usually, the client receives the new policy after some time and recovers automatically. If this does not happen, restart the computer.
Tech support have also pointed this out however, I've tried numerous reboots and it doesn't work period. Therefore, CS10.01 is broken technology in my view.
I'm not happy either as there appears to be further problems regarding CS10 documented in the release notes which I'm experiencing and apparently were fixed in 10.01 but aren't and I quote;
5. Fixed issues since previous Client Security version release (10.00)
- CS10.00 Firewall (Stateful Inspection) blocked several WEB sites/applications (CTS-91720)
- Upgrading from CS 9.20 to CS 10.00 failed (CSEP-515)
- Upgrade to Client Security 10.00 - Installing management public key failed (CTS-91578)
- CS installation rolls back NIF binaries and does not reset installation status in policy (CSEP-686)
I'm also not happy because it's taking on average 3-days to get a response via official channels and this isn't workable for my organisation.
I'm really disappointed I have to say having been an ardent customer of F-Secure since circa 1995 and having deployed your product to 2 medium-large organisations, that's over 2000 hosts on a network, it appears to me that F-Secure are guilty of having supplied Microsoft-style software, that's "broken technology" in plain English.
I know it's not your personal fault and I thank you for your quick and helpful responses within the forum but I'm really being presurised as for the first time ever, F-Secure is causing havoc to my users on the network as due to the above, apps which use Active-X components are being blocked.
I've also tried excluding the files/folders, etc from real-time scanning and no effect. That's always worked for me and also so far, process exclusion for this has been a dead-end.
We are currently working on a fix for the issue with upgrade from 9.x Client Security versions to 10.01 - 11.x versions. Exactly there is an issue with accessing the policy by FSMA after upgrade in some cases. Root cause is not found yet.
I will inform you about the progress ASAP.
Regarding the list of fixed issues you mentioned. All the fixes are present in CS 10.01. Your issues, which could look similar to bugs descriptions from the list, are caused by failed upgrade.
Please, try to reinstall the product. It should help.
Sorry for inconveniences,
> We are currently working on a fix for the issue with upgrade from 9.x Client Security versions to 10.01 - 11.x versions. Exactly there is an issue with accessing the policy by FSMA after upgrade in some cases. Root cause is not found yet. I will inform you about the progress ASAP.
In that case it is absolutely necessary to extend the FSAV 9.xx support deadline with at least the time period required for bugfix! It is neither legal nor acceptable to demand that customers upgrade to a known faulty software!
Regards: Tamas Feher, Hungary.
As it was discussed in this thread earlier, the problems appear with policy based upgrade scenario. In this scenario the upgrade is handled by the binaries from currently installed product (9.x). This binaries can't perform the upgrade correctly in some cases. The issue was reported by several customers. For them 10-20% of upgrading hosts fell in the problem with reading policies after upgrade.
We are now trying to figure out the root and find a workaround, better then uninstallation/reinstallation scenario, which helps always. Unfortunately, currently we are not able to reproduce the fail, so investigation can take significant time.
Tamas said> In that case it is absolutely necessary to extend the FSAV 9.xx support deadline with at least the time period required for bugfix! It is neither legal nor acceptable to demand that customers upgrade to a known faulty software!
I'm afraid Vad that I totally agree with his statement as this issue so far has affected every single client of mine and I've successfully upgraded none.
All have resulted in not being able to connect to the PM and worse than that, even after a reboot, they still won't connect to the PM.
If I distribute policies across the network to uninstall F-Secure, I could have hundreds of hosts without any AV and this completely negates having this provision in the PM!
I'm glad I didn't attempt to upgrade the PM as clearly v11 still has this issue.
I think v9 support needs extending until F-Secure fixes this nasty upgrade bug! Or at least ensure that the signatures, etc will work for the time being.
For the record, this problem doesn't occur when updating CS 9 -> CS 11.00 with 3rd party management system (ConfigMgr 2012), even though some components that were installed with the 9 remain on the target even though they're not in the .msi -package of the 11 that's been deployed.
Haven't tested the built-in console method at all.
We have finally Client Security 11.51 service release, which should fix the upgrade issues.
It will be published officially as soon as we get a confirmation from affected customers. If you want to verify, whether it helps in your case, please, contact support.
That's great news for v11 users but how about those on v10? It's not as simple for us as we need to update the PM which I don't want to do right now.
Could this fix not be applied to v10?
My immediate priority is getting my remaining clients off v9 as I expect are a large number of your customers also trying to do. Once this has been completed, I'll upgrade the PM server.
The only reason I don't want to upgrade the PM server is due to the fact that I understand it's quite different and has many more settings to understand and currently, I don't have the time or resources for this.
Is this correct or is the PM v11 almost the same as v10 PM?
What version of PM do you have now?
Note that CS 11.x Premium and Standard have different requirements for PM version.
CS 11.X Standard requires PM 10.10.
PM v.11.x supports Software Updater. That's the main difference from V.10.x.
We are still collecting the feedback from affected customers. As soon as we get enough confirmations, that the upgrade problem is fixed by this new release, we'll publish it on the website and Partner Portal. I hope, it could happen this week.
Meanwhile you can get CS 11.51 from support.
I can confirm that this works as it should now as I've successfully done around 200 computers.
In order to successfully complete this, I had to upgrage the PM from v10.20 to v11.10 which was fairly straightforward, just make sure you follow the instructions and backup your settings and database first!
However, I'd like to see Client Security v10 removed or fixed otherwise it's broken software which is unusable for those upgrading from am earlier version.
The EOL date for v10 is only a few months shorter than v11 so a fix should be made available otherwise, please just remove it from further download and notify/warn customers that there's a major issue when upgrading the software.