Symantec Management Platform (Notification Server)

Howdy,

I'm having a problem figuring out a way to accomplish my goal properly. I want to setup a child NS in the DMZ for our pc's with agents installed to talk to when they our outside of our MPLS. Now in the KB and documentation they explain how to setup a standalone NS in the DMZ but nothing about the layout I want. The biggest problem here is that how do I get the clients to talk to the Root/Parent NS while in the MPLS and to know to try the child NS in the dmz when they fail to communicate with the parent? The closest solution I could think of was writing a batch file/script to check and see if it can find the Root NS and if so do nothing, but if it can't modify the PC's HOST file to redirect the pc to the child NS under the root's hostname. We purchased this software in the first place because the engineer and sales manager assured me this was totally possible but I'm being told from multiple people that it's not....Even the consultants we fired said it was easy in their SoW but they proved to be too incompetant to just install the basic CMS. This is not a reliable enough solution I feel so if anyone has another way please share! Any assistance is appreciated!

Thx,

Paul

I've shared my reservations with you on Altirigos, and I hope by exposing this question to a larger audience that we can get you some help or ideas. It remains my opinon this has to be client driven, by having a 'roaming' client model, that is available (somewhat) in SEP.

Altiris is not, at present, designed to support PCs communicating with different NSs at different times...the servers just don't share configuration information well enough for that to work effectively.  I'm not saying it can't be done, but you'll be fighting against the inherent design constantly.

What you might be able to do is work with a proxy server in the DMZ rather than a full-fledged NS.

Let's say your internal server is called NS1.company.com.  You set up your internal DNS to point to the NS for this name, so whenever your PC has access to the internal DNS servers, either directly by being on the network, or when connected via a VPN type connection, they will directly communicate with the NS.

Set up your external DNS however to point NS1.company.com to the proxy server, and have the proxy server proxy those connections to the NS.  So, if the PC cannot talk to your internal DNS servers, it will talk to the world-public DNS and hit the proxy.  The critical part here, the PC is always actually receiving configuration from the same NS, not a different NS depending on whther it's inside or outside.

It steps outside of a 'pure' Altiris\Symantec solution, however, as you pointed out, one doesn't exist today. Even within a hierarchy, if a client is pointing to a child NS, and the child NS fails, I have no warm fuzzy that it would be 'picked up' by the parent NS. You could remove the child NS from the hierarchy, but you would still have to redirect the clients, via policy or script (happy to be corrected by someone in the 'know').

I have heard of plans to implement a 'roaming client' model, however very little details are available. I would still classify this as a 'wish or rumor'.

Jeff's idea may be your best route.  A few things you could do to make it more resilient:

• Use a non-standard port (say, 955 or something, check IANA for available ports, maybe in the 914-998 range which is unassigned).  Set this port as the default in the targeted Agent configuration settings (i.e. http://ns.company.com:955/Altiris).  This also allows you to apply QoS filters to traffic on this port to deprioritize traffic to/from the NS at your remote sites (assuming your routers support QoS banding).
• You can add port 80 as an alternative port to simplify accessing the console from within the company network. 

One thing to consider for my "transparent proxy" concept, however...

You need to do the port setting on both the proxy server and on the Notification Server itself.  You can't run on standard Port 80 on the inside and on 995 on the outside...that would require the machines to know where they are before doing anything.

As they used to say at Manage Fusion "Shameless Plug". Not that I'm volunteering you or anything Jeff.

No pressure Jeff ;)

We set the port in our Agent installation command line so it is there from the start.  The way I was envisioning it, the proxy would run on port 955 in the DMZ, and the NS itself would internally use that port and 80.  The proxy would forward to the NS on 955 through the DMZ firewall.  All clients would use the 955 setting in their Agent configuration, but internally (within the network) you could also use default port 80 to access the console.  This is how we have it set up (minus the DMZ proxy server; our remote users are pretty good about connecting to VPN so they can hit the NS from outside).