Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 2803 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SUM, Subscriptions and folder naming (numbering)

QC

SUM "magically" creates folder names for the subscriptions. The question is whether there is any way to control which numbers are assigned (apart from the "basic" S000).

Let's assume you have two independent management servers which both manage about half of your clients. In your updating policies you want to use each as the secondary for the other. This requires that the same folder name (Snnn) is used for the same subscription on both servers.

Now I think this can be tricky. As far as I found out SUM now uses consecutive numbering and for new installations the first additional subscription gets S001. The first versions of SUM used a different scheme (looked like the numbers were somehow derived, the software for MAC OS X 10.2/10.3 had S036).  It looks like SUM somehow remembers the last number used - even if I delete all but the "Recommended" subscription if I later add a new one it's assigned a new number.

Christian

:4112


This thread was automatically locked due to age.
Parents
  • 0

    Hi All,

    This issue was rised by me with Sophos. The auto naming of the CID ### is a real issue for me also. My work with Sophos provided a ticky work around which I have still been slow to apply in my planning.

    We use fix or previous subscriptions to provide a delay in engine changes to Windows servers and Labs.

    If an endpoint is going to have a failover to another managed update site the following is required:

    The two sites will need to share the same subscription so the CID ### match. Even if the subsrciptions are hosted on different SUM servers.

    Another issue we have is mirgation to new versions:

    If you wish to mirgate slowly from SESC 9.0.5 to SESC 9.5.1 the present design of SUM will not allow this. The moment you change your recommended subscription from SESC 9.0.5 to SESC 9.5.1 it creates a new CID ### breaking the update paths for endpoints not managed within a EMC group.

    If the endpoints are managed in EMC groups a new update policy is forced out automatically to the endpoints to redirect them to the new path. Unit the endpionts receive this update policy their updates are broken.

    I'm working with Sophos development to see if this can be changed.

    :4360
Reply
  • 0

    Hi All,

    This issue was rised by me with Sophos. The auto naming of the CID ### is a real issue for me also. My work with Sophos provided a ticky work around which I have still been slow to apply in my planning.

    We use fix or previous subscriptions to provide a delay in engine changes to Windows servers and Labs.

    If an endpoint is going to have a failover to another managed update site the following is required:

    The two sites will need to share the same subscription so the CID ### match. Even if the subsrciptions are hosted on different SUM servers.

    Another issue we have is mirgation to new versions:

    If you wish to mirgate slowly from SESC 9.0.5 to SESC 9.5.1 the present design of SUM will not allow this. The moment you change your recommended subscription from SESC 9.0.5 to SESC 9.5.1 it creates a new CID ### breaking the update paths for endpoints not managed within a EMC group.

    If the endpoints are managed in EMC groups a new update policy is forced out automatically to the endpoints to redirect them to the new path. Unit the endpionts receive this update policy their updates are broken.

    I'm working with Sophos development to see if this can be changed.

    :4360
Children
No Data