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.
Please, provide collected fsdiag to support, and drop a message here.
The workaround which works in all known cases is uninstallation of old CS (could be done from Policy Manager Console) and then push installation of the new one.
Why are you trying to use old Policy Manager and old Client Security?
F-Secure Policy Manager is now 11.10 for Windows and Client Security is 11.50.
Best Regards: Tamas Feher, Hungary.
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.
This topic has been closed due to inactivity. If you would like to discuss this topic further, please start a new post.
You can reference this topic in your post by adding this link: