Thread Info
Options
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.
  • 0

    Meanwhile I've contacted Support and the answer is, that the serials (that's the correct term for the Snnn folder names) can't be - forgive the pun - serialized (just in case someone from Sophos wants to check, case ID #2423202).

    It is in fact not a minor problem for me. Computers from the domain have a WebCID as secondary update location (mainly for notebooks when they are not "inside" - but recently the primary server has been unavailable for some time and to have the secondary was an advantage). The server hosting the WebCIDs has an independent SUM - no problem for the Recommended subscription (as long as I subscribe to the same SAV version). I don't want to migrate to SAV9.5 in one fell swoop but as it is now this doesn't seem to be possible: The new subscription in the domain has serial S001 whereas the other SUM has S073 assigned. So clients from the domain won't find the WebCID (which they expect to have serial S001).

    I'm surprised that seemingly I'm the only one having a problem with it

    Christian   

    :4319
    • 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
      • 0

        Thanks, VCU

        Count me in - do you have a reference (case or defect ID) I can pass on to my Support contact? Or is there a better ay to get on the "interested parties" list?

        Christian

        :4386
        • 0

          Hi QC,

          My work with Sophos on this covers many case numbers and is now being investigated by UK development. I will pass along that another customer beyond myself is interested in getting this addressed. It is unclear to me how to add you into the work I'm doing on this issue. Perhaps if you called Sophos tech support and covered with them the issue you have they will have a collection process like the feature or defect listing where they add individual entries together. I believe I heard one of the Sophos technician say this is something they do and the more requests they have for the same thing the faster it is addressed.

          I will post an update here on what is learned from my work with Sophos.

          I hope this helps.

          :4399
          • 0

            Hi QC,

            I was able to include you into the cases I already had open concerning this issue. The Sophos engineer even created a new case 2439271 to combine the items so it will make it easier to address.

            Thanks,

            VCU

            :4567
            • 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
              • 0

                Thanks, John

                Short term: when I encountered the problem one idea was to use a legacy updating policy to specify different serials. I don't know if this will break something with the 9.x AutoUpdate. I could test it but unfortunately (depends on how you see it) on SEC is a fresh install without EM and legacy policies are not available so even if it works it would be of no use (unless legacy policies could be enabled).

                Christian

                :4601
                Unfiltered HTML