Read this before deleting a Satellite manifest in the customer portal (for disconnected satellites)

Good thing to remember... Save yourself some work - If you have disconnected 6.2 satellites (not sure if this affects 6.3), and create manifests in the customer portal... Keep (do not delete) the manifest in the customer portal. The not immediately clear warning that comes up really translates into English that if you delete it (in the Customer Portal) there's no chance you will ever be able to accept a new satellite manifest without first deleting (on your disconnected satellite) the manifest and go through the pain of reassigning entitlements to all hosts, activation keys and so forth.

I'm hoping that someone else is saved from this pain we discovered as a result of this. Yes it's documented, it sadly is not clear until after the fact and have to deal with the aftermath.

That being said in retrospect, it's not as terrible as I had thought before going through the resulting path needed to delete the manifest and then reassign entitlements.

Just for reference, Here's what Red Hat mentioned... added in retrospect, it turned out not as bad for my location. Now depending on the sheer number of systems you have, it may be a tad more difficult to determine. Our systems have a mostly straightforward naming convention that in most cases is easy to identify what is a server and what is a workstation. So I was able to en-masse assign entitlements using the Content Host view (where hosts are on the left), and then take a "Bulk Action" to assign subscriptions. Before that, I assigned the necessary subscriptions first to the satellite server, ensuring the "satellite" entitlement was assigned.

When uploading a manifest over the top of a different 
manifest, the error that you encountered is seen. When 
you upload a new version of the same manifest over the 
top of a current manifest, you do not get the error. This is 
because each manifest has a uuid that is listed on the 
portal. The satellite uses this uuid to communicate back to 
the portal to pull the updated list of entitlements that were 
added/removed in the event of a refresh.

If you wish to upload a new manifest, then you are required 
to delete the current manifest, since the uuid's are different.

In the host configuration guide, here is a note[1]:

'Manifests should not be deleted. If you delete the manifest 
from the Red Hat Customer Portal or in the Satellite Web 
UI it will unsubscribe all of your content hosts.'

[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions#Managing_Subscriptions-Updating_a_Manifest

When deleting the manifest from the customer portal, this 
warning is presented:

"Are you sure you want to delete this subscription 
management application?
This action will remove all subscriptions from this 
subscription management application and permanently 
delete the subscription management application. You 
cannot undo this action."

That said, you'll need to delete the manifest from the 
satellite webUI before being able to upload a new manifest.

I cannot promise that the re-registrations and re-entitlements 
will be automatic, but you are welcome to wait 24 hours 
and see if this happens.

Hoping this post helps someone else avoid the pain I apparently inflicted on myself - and now I know.

Original post turns out the aftermath is not as bad as I thought, see preceding notes

Bottom line, I'm experiencing issues uploading and getting our disconnected satellites to upload/accept our recently renewed manifests, our satellites had expired while had our support renewed (lag of a couple weeks). I do have a priority ticket with Red Hat #02049342 but I'm curious if anyone else has faced this issue and found some resolution - I'd appreciate any help.

I have several RH Satellites, 2 of which are "disconnected" satellites at version 6.2.11.

We just had the majority of our entitlements renewed for support, so I'm going through what I go through each year, re-uploading our RH Satellite manifests.

So yes, I made sure to select the proper version in the satellite manifest/certificate creation tool. I also deleted previous manifests/certificates from the web portal (not in our disconnected satellites, but in the Red Hat Customer Portal). I've done this before.

I also made sure the proper set of entitlements is assigned, the satellite itself, and the appropriate number of entitlements for RHEL server/workstation and oracle things to cover all the systems. so there is no disparity with the number of entitlements supported. There's room for growth.

I made sure to be in the proper context (organizational, location), we only have one organization. And we just use "default location".

I had at one point considered deleting the manifest on my disconnected satellite, but a warning in the web interface pops up with this set of not-good consequences:

| "Delete Manifest"
| Are you sure you want to delete the manifest?
|
| Note: Deleting a subscription manifest is STRONGLY discouraged. Deleting a manifest will:
|
| > Delete all subscriptions that are attached to running hosts.
| > Delete all subscriptions attached to activation keys.
| > Disable Red Hat Insights
| > Require you to upload the subscription-manifest and re-attach subscriptions to hosts and activation keys
|
| This action should only be taken in extreme circumstances or for debugging purposes.
|___________________________________
That warning seems "Pretty Strong(TM)"

If I really had to, like no other option, I could delete the manifest on my disconnected satellites, but I've never had to do that before (we go through this every year, and we've been using RH Satellite 6.2.x for a while now). Based on the pop-up warning I typed out above, it seems like a considerable amount of work to manually reassign all entitlements to systems, activation keys etc. I could do that, but I've never had to do that before, and it seems like a lot of work that if possible ought to be avoided if a better method could be used.

Appreciate any assistance