nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

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

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?

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.

LakshmananVenkatesan

Can you share which version you can able to reproduce?.

JonathanQuinn

It was a dev build of the software so not on a released version. Have you reached out to Support?

ValeriaEstrada

Hello, has anyone found the solution? I have the same issue on 10.5.1. It happens with the timestamp and without it too, duplicating all kind of services

MiguelGarriga2

Having same issue with Portal - Content shows multiple map services with same name. The names do not contain timestamps, names are identical. Has anyone discovered how to resolve this ? Thanks in advance.

IMG_9g4wu1.jpg

JonathanQuinn

Can you describe your setup? For example, is it HA or not HA? Is it a distributed environment or single machine setup? What URL did you use for the admin URL during federation? Did you set the privatePortalURL in Portal prior to federating?

DamianSlee2

I have similar issues, I think there is no other option other than cleanup the temporary service and portal items after a failed service update.

BUG-000114507 : Portal for ArcGIS creates duplicate items upon overwriting an existing service in a federated server, failing due to inaccessibility of data.

MarcCavallaro

We are experiencing this service duplication issue on Portal 10.6.1. Any solution to this?

DamianSlee2

unfortunately, have the implement your own cleanup scripts after a service fails to update.

there are

- temporary service_date and portal items

- also the original service definition json gets updated with the additional new portal item ids as well and json attribute derived="True". so each time a service update fails, if you look at the original service there is extra map service portal item references.

lcatania

I don't see BUG-000114507 listed as open or closed. Is it still open? Is there a patch? Why is it not listed when I go to the Bugs section of My Esri?

Anonymous User

BUG-000114507: Portal for ArcGIS creates duplicate items upon overw..

Says not in product plan, soooo I guess that means they are ignoring it and making us fix it ourselves?

We're just spinning up a new 10.7.1 enterprise deployment and I noticed this with testing. Considering this was submitted June of 2018 it is HIGHLY disappointing nothing has happened after 18 months.

DougGreen

We have just had this start happening on a 10.7.1 on windows 2016 with a federated server. It started being observed a couple days after updating our ArcGIS Server to use a new self-signed wildcard cert. We have tried using the same cert on our portal machine to see if that resolved the issue but it has not. Our architecture is as follows:

Server A: ArcGIS Server, Data Store (inside firewall, Self-signed Cert)
Server B: Portal for ArcGIS (inside firewall, Self-signed Cert)
Server C: Web Adaptor for Server, Web Adaptor for Portal (outside firewall, CA Cert)

We are somewhat surprised that this is still just sitting here with a bug like this unresolved. How have you all moved past this or are you just using this method to delete the orphaned items constantly?

DougGreen

For anyone else experiencing this issue, our cause for these errors was that we had just received a new certificate for our internal servers that would work for any server on our internal network (an internal wildcard cert). This was a pfx file. We imported it and enabled it and the web browsers stopped complaining about insecure websites. However, the individual pieces of the architecture were not liking it. Also, programatically interacting with the portal or server through python or rest api was throwing ssl errors. The problem was that we had not imported a root or intermediate .cer file. Apparently this is needed to complete the validation route. Once that was in place on both Server A and Server B, we were back in business. It took a 3 hour chat with Tech Support but we got it.

MikeVolz

So which server(s) should the root or intermediate .cer file be imported to - Portal server and/or all ArcGIS Server machines (AGS role, image server role, etc.)?

DougGreen

Sorry I'm just seeing this. It has been too long and I don't remember but I think it was just the ArcGIS Server machine. We are just finding that it's doing it again after upgrading to 10.8.1. I'm going to be on the phone with them again it looks like.

JoshB123_1-1734353024756.png

Anonymous User

These were the only notes I jotted down after finally getting ours to work in January. I couldn't get this to work on 10.7.1 and had to use 10.6.1 to get SSL certs to take. Then update to 10.7.1. Just updated to 10.8.1 and not having any issues yet.

Wildcard external domain from GoDaddy imported into IIS. Manually export each level (root, 1st intermediate, 2nd intermediate, full cert to pfx) from IIS. Import root, 1st, 2nd certs into server, import current server cert and import wildcard pfx file.

Import domain level wildcard for [yourdomain] network. Import as current server cert in server admin, set the server to use that cert instead of selfsignedcertfiicate. Now internal access is secured with domain cert, external traffic through web adapter is secured with godaddy cert.

Here's what certs look like on my server:

And on my Portal:

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.

Capture.PNG

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.