Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 29 replies
  • Subscribers 1 subscriber
  • Views 21767 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

Upgrade error when updating to Enterprise console 4 on a air gapped network

NLNAV

Hello,

I'm trying to upgrade my enterprise console 3.0 to 4.0 en finally to 4.5. The upgrade of the console succeeded but i receive an error when i want to configure the update manager. The error is: "couldn't create cataloque sdds.local".

The enterprise console is on an air gapped network. I copy the complete library folder from an server connected to the internet to my air gapped server. The sophos service account has full control on the folder where i copy the library.

I have a seperate SQL server which is succesfully upgraded to 4.0.

The server which is connected to the internet is not yet upgraded to 4.0. Can this be the problem? Can i still use the update's on my old (3.0) configuration when i upgrade this server to 4.0?

Are there any idea's what the problem could be when is not the update folder?

Witht best regards,

Peter

:10299


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

    Sorry for the delay, Peter

    So what can i do next to remove the "orphaned" EM library

    Once you stop using the legacy policy (i.e. assign a "new" policy instead of it) SEC should let you remove EM Library.

    the proper procedure is for removing the EM library

    Well, what I did is:

    1) Review your (legacy) updating policies. This is especially important if   

    • you have been using "customized" CIDs (e.g. .xml configuration files or mrinit.conf)
    • you are using products for other platforms
    • you are using WebCIDs

    Reason: Policies have changed and no longer include the path to the product. The part below the share (CIDs\Snnn\<product>) is set depending on the subscription 

    2) Create the new policies (and additional subscriptions if needed)

    3) Assign the new policies instead of the legacy ones (if you have many groups this is a tedious process - or a ruminant exercise if you want to put it that way)

    4) check if the clients are using the new policies

    5) "delete" EM Library from the console

    6) uninstall EM Library (and eventually delete the CIDs)

    If you have unmanaged clients (or clients which only occasionally "show up") you can customize your legacy CIDs with SAUConf.xml in order to point them to the new locations  

    Christian

    :10967
Reply
  • 0

    Sorry for the delay, Peter

    So what can i do next to remove the "orphaned" EM library

    Once you stop using the legacy policy (i.e. assign a "new" policy instead of it) SEC should let you remove EM Library.

    the proper procedure is for removing the EM library

    Well, what I did is:

    1) Review your (legacy) updating policies. This is especially important if   

    • you have been using "customized" CIDs (e.g. .xml configuration files or mrinit.conf)
    • you are using products for other platforms
    • you are using WebCIDs

    Reason: Policies have changed and no longer include the path to the product. The part below the share (CIDs\Snnn\<product>) is set depending on the subscription 

    2) Create the new policies (and additional subscriptions if needed)

    3) Assign the new policies instead of the legacy ones (if you have many groups this is a tedious process - or a ruminant exercise if you want to put it that way)

    4) check if the clients are using the new policies

    5) "delete" EM Library from the console

    6) uninstall EM Library (and eventually delete the CIDs)

    If you have unmanaged clients (or clients which only occasionally "show up") you can customize your legacy CIDs with SAUConf.xml in order to point them to the new locations  

    Christian

    :10967
Children
No Data