Multiple policy domains with the same name

Popeye

Hello.

 

In previous versions of PM, you could not have more than one policy with a given name. Thus, if I had one policy domain called "F-Secure \ ClientSecurity \ v9.20", I could not have another policy domain called "F-Secure \  Antivirus \ v9.20" as "v9.20" would be the same name even on two different locations in the domain hierarchy.

 

Today (in PM 10), I accidentally created a policy domain with the same name as another policy domain on the same level - I created the policy domain "File" twice and PM let me do this. They were even subdomains of the same policy domains, i.e. on the same level right next to each other.

 

Does this mean that it is now OK to have multiple policy domains with the same name? This would be a big plus for me, as I would no longer have to have domains called for instance "AV-v9.20" and "CS-v9.20" to keep the names different.

 

Thanks in advance!

MJ-perComp

Hi,

this feature was requested long ago, as many customers organized their domains by location first, then by servers and workstations.

 

Still it would be interesting to understand why you set up such a naming scheme? What is the benefit?

 

Cu

 

Popeye

The reason for the design of our policy hierarchi is historical. To put it short (hopefully) and exemplified:

 

1. We separate Client Security, Antivirus for Workstations and Antivirus for Windows Servers into separate top level policy domains (scond level domains, actually, under the F-Secure top domain).
2. Within each product's policy domain, we separate on a few functional or organisational policy domains (i.e. "IT Dept", "Info TV", geographical locations or similar for Client Security).
3. Each functional or organisational domain is separated into versions, to make it easier to keep track of what clients have what version of the product in question (this is the historical part).

One reason for separating on versions is because in earlier versions of PM it was more troublesome to push upgrades to different versions in the same policy domain. If I wanted to upgrade only CS 8.00 to CS 8.02 and leave 8.01 untouched it was easier to separate versions into different domains. With PM10 I can push a policy install to upgrade only CS 9.01 clients to CS 9.20 even if there are several other versions in the same policy domain.

 

By separating clients into different version based domains, it is also easier to get a quick overview of how the different versions are distributed throughout the hierarcy. I delete empty "version domains" regularly, so only populated "version domains" exist.

 

Was that even comprehensible? English is not my native language, and it's easy to forget something when describing our solution... Ask if something is unclear.

 

And please: Feel free to suggest better domain structures. I guess you have a broader experience from a lot of different installations, while I have only my two PMSes (separating students employees on separate PMSes).

MJ-perComp

Separating into different versions should no longer be needed with PM10 as you can select multiple machines.

PM10 still need some more improvements to handle Hotfixes as well.

 

Nevertheless I highly recommend to distribute the same version on  the machines.

 

AND I guess you only mentioned 8.01/8.02 as an example to explain, but in reality you have no old 8.xx installtions any more??!!

 

 

 

 

 

Popeye

So far, I have kept the old policy hierarchy just because it works. A major restructuring job is due, but not until sometime next year. I wantet to get some time with PM10 before I did anything, to avoid doing things the wrong way. I also have two F-Secure deputies that get confused if I change things too often (meaning if I do anything at all)...

 

The reason we have several different versions is mainly because not all computers get their installation at the same time. When a new version is released, I seldom upgrade thos computers that are "almost there" version wise, meaning that if 500 computers have version 9.11 installed I will not push 9.20 unless there is a very good reason to do so. Our employees do not like forced reboots every now and then, and they certainly do not like a forced upgrade when in meetings or doing presentations or classes (I work at a business school with some 8000 students at our campus). Having 500 computers running version 9.11 is not a big crisis, as long as there are no major flaws or "feature shortages" in this version.

 

And yes, I only used Client Security 8.01/8.02 as examples. I am smoking out the last 8-10 version 8 installations this week, resulting in all 1700 computers running CS 9.11 or higher.

MJ-perComp

Just in case you upgrade to 9.20, there is a problem with the setup when around the Reboot-Options. Check the release notes carefully.

Popeye

Problem with reboot options in 9.20? I haven't noticed this myself, and have had no reports of this from my users, and I currently have well over 500 PCs running 9.20.

 

BTW, I distribute the push installations including a rather strict, selfmade policy set, so it doesn't matter if it takes several minutes for the computer to get a policy from the server.

 

I see that 9.30 has an issue with being slow after the first reboot after a fresh installation, but that should not be a big problem here as most computers are receiving an upgrade, not a fresh install. I'll perform my first push installations this week to get some experience with this version, and then move for a bigger push in the first week of 2012, before our students return to campus.

 

We do not use MS Outlook/Exchange, so we are not affected by the mail bug that was reportet in 9.30 earlier today.

MJ-perComp

Mailbug is not restricted to outlook. We were able to repro using telnet. So any POP3 or IMAP Client will be effected!

Popeye

We're one of those dinosaur companies that still use Lotus Domino/Notes, so we are not affected. Domino/Notes communicate on TCP/1352 with encryption, so F-Secure is blissfully unaware of what's going on.