Portal items duplicating on service update

[LakshmananVenkatesan]

Hello All,

We have ArcGIS Server 10.4.1 federated with Portal running on Windows 2012 R2. One of client (Publisher role) published a map service in server and layer item was created in portal. When he tried updating service - just changing label and overwriting the existing service, duplicate portal item was created.  The client was original owner of portal item at the beginning (ensuring he was not updating others contents) . He uses ArcMap for publishing with same credentials and everything is same. User is not altering any security settings in portal.

I would like to understand what are all possible scenarios for duplicating the portal items?.

Please provide more insights on this case. 

[JonathanQuinn]

Does the duplicate service item have a timestamp appended to it?  For example, <service_name>_201702012017?  The overwrite workflow actually publishes a new service with a timestamp, makes sure it publishes successfully, deletes the original and renames the new one.  It looks like that process leaves an "orphaned" item; the service item without the timestamp is the correct once and the service item with the timestamp isn't valid.

[LakshmananVenkatesan]

Hi,

Thanks for your quick response. We have two cases - last week, when user tried to publish we could see duplicate item with underscore time stamp. But unfortunately we have both the items one with underscore timestamp and original.

Yesterday - duplicate item has exact same name except date is different. User mentioned that overwrite service was successful without any error while publishing. FYI.

How do I find such orphaned items or how can I reproduce the issue? 

Thanks again

LV

[JonathanQuinn]

Can you describe your setup a bit?  Is the Portal HA or is the federated Server site a multi-machine site?  What kind of security?

Orphaned items will be the ones with a timestamp, so <service_name>_<timestamp>.  If there are two services with the same name, one has a timestamp and the other doesn't, it's likely the one with the timestamp is invalid.

[LakshmananVenkatesan]

This is a single machine site- i.e server is federated with one portal . As said in my reply, I could see two items with same name.

Thats the whole confusion and how it was created?

[akochman]

Still happening in 2021 on an EC2 single machine deployment (10.8.1), server federated with portal. I detailed in another reply but we have 1 signed cert (not wildcard) for our domain. The default self-signed certs for Portal/Server are still active and our internal browser's do not recognize our machine name/localhost as secure, but our domain is secured.

Are any of these solutions Esri supported? I assume everyone with an EC2 will have to do something for this issue? Support mentioned to add an SAN with the amazon domain, like (slides 23-25), but that is not an option since it is blacklisted. Support said it is out of their scope, yet our Enterprise won't function properly until this is resolved. (so how is it out of scope?)

[akochman]

Update: Worked with a very helpful support analyst who helped install our domain SSL properly on within Portal Admin. Once installed, the orphaned/duplicate services were no longer appearing when overwriting services. We also binded our domain as the host name within IIS, so internal access via the machine name is not possible anymore.

Here's a screenshot for anyone else having the issue I had previously.

[CarmelConnolly3]

I'm experiencing this issue as well - it happens intermittently and we're on a federated 10.3.1 Portal.

At the moment, I'm receiving the generic error '001369 : Failed to create the service.' when attempting to overwrite a service.

I have admin rights and the service is sitting in the root folder in Portal.

[LakshmananVenkatesan]

welcome to club

[JonathanQuinn]

I was able to reproduce this on one deployment but not another so it does seem intermittent.  I'd suggest you reach out to Support so they can investigate and log a bug if necessary.  I'll continue to do some additional testing in the meantime.