Symantec Management Platform (Notification Server)

THis is more a question relating to "usability" within a multi-NS environment.

Scenario is - 2x NS's.  Client computerss point to NS2, NS1 is at top of hierarchy.  They are replicating.

I want the service desk/front line staff to be able to quickly provide pre-defined software to users that call.  I envision having the applications pre-defined in the software library on NS1, and the service desk staff, upon receiving a phone call from a user, should be able to easily send a quick delivery task OR put the user's PC into the appropriate destination filter for the managed delivery.  ALL FROM NS1.

Unfortunately, I am concerned that if either the quick delivery task or the filter config is done on the top level NS, they'd have to force replication to NS2 to make things happen quicker. 

What do the rest of you do for multi NS environments with single service desks?  *I want the service desk staff to ONLY use NS1, they should not have to think about which NS they need to use.  Eventually we will end up with about 3 lower level NS's*

I guess I could replicate tasks downwards every 5 minutes so that the software gets out to the users within 5 or 10 minutes, but this seems potentially dangerous?  I don't want the service desk staff to have to jump between multiple NS's.  This is for Mac and PC clients.

Thoughts, opinions most appreciated.

I'm not a replication or hierarchy expert, so I can't answer.  But why so many notification servers?  I'm sure there's good reason to have five NS's, but sometimes folks get carried away thinking they need one in each state or region when they really need site servers.

We're not going to definitely have 5 NS's, but this is where it *could* head in the future.

Basically, we will have 2 to begin with, but based on current limitations with NS7 and CMS scalability, the limit is around 6000 per NS.  With 20-25K clients, that equals 4x client facing NS's and 1 top level.

Of course, NS7.1 will hopefully increase the maximum clients per NS when run on a 64-bit platform so I would say we won't go with that many, but strictly speaking, 6K is the recommended maximum per NS with CMS at this time.

Try to use the package delivery task when trying to install a software directly from parent NS on to clients of child NS.

So in a service desk scenario (not the product, I mean a real service desk with real people), the service desk person receiving the call should add the user's computer to the target filter for the app, but that won't install until replication, followed by agent connection (which I have set to 1 hour). 

If the user needs the app ASAP, the service desk worker needs to fire off a package delivery task.  But won't that still require replication to take place prior to it getting to the client machine anyway?

I was under the impression that the agent will download the package from the closest server that has the package, so if the site server does not have the package it should still download the package from the originating server.

That part is understood and hasn't really changed.  This is more about the impact of hierarchy on timings, policies, tasks and how long a software policy change takes to reach a client computer.

And I found another problem... If you have a complex software delivery policy, there's no way to make that easy to run on a client machine in a short amount of time, particularly in a hierarchy scenario.

In a scenario where a user requests software and a policy is required to deliver it, you need to add the user's computer to the target/filter, replicate the filter, then send a "get client config" job to the client.  Not the most efficient way of doing this and certainly more cumbersome than a simple package delivery task.  But there's a lot of packages that need to be delivered in this way.

Creating a complex task is an option too, but then you are creating work twice.

Please let me know if you ever find another way of doing all this.

There's too many options and not enough solutions.

- Service Desk worker connects to NS and delivers the package via package delivery task, right click and replicate now (runs in about 5 minutes).  Can only use it for simple packages.
- For complex packages, add user's computer to the target filter for the policy, replicate it now and it will install at some point... But not immediately.  Maybe send a get client config task to the client.  Not such a simple "point and click" operation that marketing would make us believe, unfortunately.
- Connect to the child NS and do it from there (not such a good solution, what's the point of hierarchy if you have to do this?)
- Advertise the package on the portal, but oh yes, here's a great limitation - if you advertise a policy on the portal from the parent, the fact that it's in the portal won't replicate.  So you have to do that from the child instead, and create policies there.

Aaargh

Wallo,

Sounds like we're in similar situations.  20,000+ clients has forced us to 4 tier 2 NS's.  We have found that the only way to delivery a piece of software and report on it in a timely manner is to use a quick software delivery task.  I don't think a policy will get the job done.  You also have to consider a package server (site server) should be close to the client.  We also discovered that the results of the task do not replicate back to the tier 1 NS for reporting.  This data needs to be retrieved from the tier 2.  According to Symantec, this is by design.

 

Hope my input helps you out.

Kris