Endpoint secV9 and Standalone computers, not showing in enterprise console

Back to the basics, Stefano. I think there might be a misunderstanding.

Now I don't follow the order of the tasks necessary to protect and manage the clients but I'll start with the "target configuration" explaining some things and try to work backwards.

In a running environment there are two "communication paths" from client to server

1. Updating:
   -  you can either use SMB (shares) or http ("WebCID"). The contents are the same so you can simply publish the share on the web (it has been discussed already here) - you don't need an extra subscription for this
   - thus you need either port 445 (or the "older" NetBIOS ports) open into your domain or at least a port for http to the webserver
2. Management (this is a crude description, I'll spare you the rather complex details), aka RMS
   - clients talk to the server using ports 8192-8194 on the server and the server either actively sends messages to the client using 8192-8194 on the client ("two-way" communication) or by sending them as "replies" when the client contacts the server.
   - minimum requirement is ports 8192-8194 to the server from "the Internet" (or better by using a message relay in the DMZ as described in article 14635, which in turn must have a communication path to the management server)

What is the necessary configuration?

1. Updating
   - in principle all you clients could use the same configuration. Specify the share as primary and the WebCID as secondary location. Outside clients will try SMB and as this fails they will fall back using the WebCID. Voilà.
   - to build the installer you need the sauconf.xml file as described 
2. RMS
   - this is where mrinit.conf comes into play. By default it is set up that your clients will talk directly to the server
   - if you don't want this, you have two options
     a) use the message relay for all clients (inside and outside). It requires some careful setup for the management server and relay though
     b) use the direct path for inside and the relay for outside. You need two CIDs (or better: an additional distribution share) but still not an extra subscription.

That's it for short. An unofficial addition: all this can be set up quite flexible so that clients can be "switched" from the message relay to the central server or v.v. without the need to touch them. 

One more remark: try to use aliases for the servers/services wherever possible - otherwise your (especially the) outside clients might be left stranded in case of a server replacement

Hope this helps. Feel free to ask (if you want using PM) if you need more information.

Christian

Back to the basics, Stefano. I think there might be a misunderstanding.

Now I don't follow the order of the tasks necessary to protect and manage the clients but I'll start with the "target configuration" explaining some things and try to work backwards.

In a running environment there are two "communication paths" from client to server

1. Updating:
   -  you can either use SMB (shares) or http ("WebCID"). The contents are the same so you can simply publish the share on the web (it has been discussed already here) - you don't need an extra subscription for this
   - thus you need either port 445 (or the "older" NetBIOS ports) open into your domain or at least a port for http to the webserver
2. Management (this is a crude description, I'll spare you the rather complex details), aka RMS
   - clients talk to the server using ports 8192-8194 on the server and the server either actively sends messages to the client using 8192-8194 on the client ("two-way" communication) or by sending them as "replies" when the client contacts the server.
   - minimum requirement is ports 8192-8194 to the server from "the Internet" (or better by using a message relay in the DMZ as described in article 14635, which in turn must have a communication path to the management server)

What is the necessary configuration?

1. Updating
   - in principle all you clients could use the same configuration. Specify the share as primary and the WebCID as secondary location. Outside clients will try SMB and as this fails they will fall back using the WebCID. Voilà.
   - to build the installer you need the sauconf.xml file as described 
2. RMS
   - this is where mrinit.conf comes into play. By default it is set up that your clients will talk directly to the server
   - if you don't want this, you have two options
     a) use the message relay for all clients (inside and outside). It requires some careful setup for the management server and relay though
     b) use the direct path for inside and the relay for outside. You need two CIDs (or better: an additional distribution share) but still not an extra subscription.

That's it for short. An unofficial addition: all this can be set up quite flexible so that clients can be "switched" from the message relay to the central server or v.v. without the need to touch them. 

One more remark: try to use aliases for the servers/services wherever possible - otherwise your (especially the) outside clients might be left stranded in case of a server replacement

Hope this helps. Feel free to ask (if you want using PM) if you need more information.

Christian