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

    To clarify things, the problem isn't that the update is switching between two different SUM servers (this is supported and should just work as the subscription numbering is automatically the same), but that it is switching between two SUM servers that are managed by different SEC instances. This isn't really supported, and with larger installations (particularly with message relays) can go horribly wrong. It is the SEC instance that generates the number.

    However, it is clear that there are several of our customers who wish to do this, so we (in dev) are looking at how this can be made easier (in the short term), and properly manageable (in the long term).

    :4581
Reply
  • 0

    To clarify things, the problem isn't that the update is switching between two different SUM servers (this is supported and should just work as the subscription numbering is automatically the same), but that it is switching between two SUM servers that are managed by different SEC instances. This isn't really supported, and with larger installations (particularly with message relays) can go horribly wrong. It is the SEC instance that generates the number.

    However, it is clear that there are several of our customers who wish to do this, so we (in dev) are looking at how this can be made easier (in the short term), and properly manageable (in the long term).

    :4581
Children
No Data