|
POST
|
If you publish a non-hosted service to a federated Server, it creates an item in the portal as you know. If you delete the item in Portal, it won't delete the service. However, if you delete the service, it will delete the item in Portal. On the other hand, if you publish a hosted service, deleting the service won't delete the item, but deleting the item will delete the hosted service. If you're sure those services are pointing to the items that were deleted, the services can be deleted. This behavior has changed as of 10.6.1: https://developers.arcgis.com/rest/users-groups-and-items/delete-item.htm The deleteItem operation has changed at 10.6.1 so that when a service item that references a published service on a federated server is deleted, the corresponding service is also deleted from the server. If the item represents a capability for a service, like WMS, then the capability will be removed from its parent map service.
... View more
11-01-2018
01:27 PM
|
0
|
0
|
1524
|
|
POST
|
When you're RDP'ed into the Server machine as your account, can you reach the share in Windows Explorer?
... View more
11-01-2018
12:18 PM
|
0
|
5
|
3684
|
|
POST
|
Can you run the reindex with DEBUG logs? There should be messages about the index process itself. Sometimes the messages can point to the problem. If reindexing doesn't help, then one cause is there's a content discrepancy between the database and content directory. There are solutions, but unfortunately, require deep knowledge of the software. If the solution isn't clear through the logs, contact Tech Support who can guide you towards a resolution. We plan on improving the resiliency of the index, including identifying corrupt or incorrect indices, in the next version of the software. This would help with another typical cause of indices getting out of sync.
... View more
11-01-2018
10:22 AM
|
0
|
0
|
1895
|
|
POST
|
I replied to your other thread but I'll reply here too. If any data is in a non-registered location, the publishing process should package them and extract them in the arcgisinput location automatically. You don't need to do anything. In terms of registering the data, you can either: 1) copy the MXDs, (approach above, requires you to republish if the original MXDs change) 2) Set up your PrintTesting folder as a share, register the share, and update your scripts 3) Copy the whole directory to the Server. You'll have two separate copies of the MXDs, and your machine will reference the copy on your machine and the Server will reference the copy on the Server machine. This is not too common when the machines can talk to each other. You typically use this approach when your machine is Windows and the Server is on Linux or you're using a deployment in the cloud.
... View more
11-01-2018
09:42 AM
|
0
|
0
|
1493
|
|
POST
|
Hm, it is strange that you see different messages, but what is taking the longest? Can you add arcpy.AddMessage statements to see where it's hung up? I'd say the exception with java.lang.Exception is likely timing out as it makes it into the Server, while the message without it made it in, but times out when it's running. You may be seeing it timeout as it makes it in as all instances are being used, (since the ones that are running are hung), so you're seeing two separate timeouts. I'd start by adding statements to sort out where it's hung. You'll need to set the GP service to return INFO messages.
... View more
11-01-2018
09:36 AM
|
0
|
3
|
5328
|
|
POST
|
Thanks for posting the workaround. I tested in-house and see the original behavior and that the workaround works. We'll get this sorted out in the software.
... View more
11-01-2018
09:33 AM
|
1
|
2
|
3277
|
|
POST
|
Try the following: 1) Make sure the db folder doesn't exist in the usr/arcgisportal/ directory. That directory is under the install directory by default 2) Make sure the config-store-connection.json file doesn't exist in the framework/etc directory. That directory is also under the install. 3) Restart Portal Try to create the Portal again and if it fails, check the logs for information about the failure.
... View more
11-01-2018
09:29 AM
|
2
|
3
|
6292
|
|
POST
|
The Server account/machine needs write access to the location set for the Server path. You can try a few things: 1) Create the path on the Server machine and copy the contents of the directory on your machine into the new directory. Server will be able to access the path on it's own machine now. 2) Use a UNC share. Share the directory on your machine, then update all paths within your script, (f this is a continuation of the MXD thread), to point to the share. Give the account running the Server service access to the share. 3) Copy the data to the Server during publishing time by not registering the folder. This is really only useful if the data/resources is static and won't change.
... View more
11-01-2018
09:24 AM
|
1
|
1
|
3684
|
|
POST
|
If the MXDs are in a registered location, the path should be kept the same. If they're not, then it should be packaged up with the service and extracted to the arcgisinput folder, as you pointed out. The path in the script will be updated as well, so no need to worry about that.
... View more
10-31-2018
04:38 PM
|
1
|
2
|
1493
|
|
POST
|
There are two ways to validate the ArcGIS Data Store, one is Server validates it, (validating the Data Store through Manager or the Admin API), and the other is Data Store validating itself, (which is what you've done to receive the response you did). I'm not exactly sure what Data Store is checking when it's validating itself, but the "trust" between Server and Data Store seems to be broken somehow. It's strange that it works for a while before failing. Are there more details about why it failed when you look at the Server logs?
... View more
10-31-2018
03:14 PM
|
1
|
0
|
13640
|
|
POST
|
You'll want to run the setup for the web adaptor again to install a separate one for Server, giving it a different name other than "arcgis", (Step 4). The ArcGIS Enterprise Builder calls them "portal" and "server" by default. You can name your new one "server" if "arcgis" is already used for Portal.
... View more
10-31-2018
03:10 PM
|
1
|
0
|
2459
|
|
POST
|
Hm, so perhaps the database is taking longer than expected to start up. Do you see any errors in the pg logs under the lgos directory\database? If you were to turn on DEBUG messages before the restore, you should be able to watch for when the database is told to start, and then you can monitor when it does by watching for the postgresql.exe processes. You may want to reach out to Tech Support as this may require some digging.
... View more
10-31-2018
10:31 AM
|
1
|
0
|
3608
|
|
POST
|
This won't necessarily test the health of the services, only if they're up or not. Data issues could cause the service to return a 200 when checking to see if the service itself is accessible, but making any type of request for data, (query or exportMap), will fail. I'd suggest you just run a simple query to see if it returns data and also use built-in modules, (even though requests is far easier to work with), (where 1=1 and returnCountOnly = True). If you do want to query all services, keep in mind that it will submit a bit of load on the Server and, if the data is coming from a geodatabase, the geodatabase as well.
... View more
10-30-2018
10:24 AM
|
4
|
0
|
1765
|
|
POST
|
Those aren't errors, they're simply messages indicating that the deployment is getting itself ready to be HA regardless if you intend it to be HA or not. They can be ignored as they aren't related to the failure. What version are you using? If it's pre-10.6, then you can rename the newly created dbXXXXX folder to db and then move the .config-store-connection.json file out of the db folder and into the framework\etc folder. That'll get Portal back up and running quickly. At 10.6 and on, Portal will roll back to it's previous state if the restore fails. About the error, does this happen every time? Rebuilding the site per the instructions above will make rolling back manually easier.
... View more
10-30-2018
10:03 AM
|
0
|
3
|
3608
|
|
POST
|
Depends on how much content you have. With a new install, no custom content, it'll take under 20 minutes. Portal takes the longest to backup.
... View more
10-29-2018
10:55 AM
|
1
|
0
|
5463
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-28-2026 06:05 AM | |
| 1 | 08-26-2016 10:10 AM | |
| 2 | 02-22-2024 07:22 AM | |
| 1 | 06-07-2024 07:11 AM | |
| 4 | 12-12-2024 08:52 AM |
| Online Status |
Offline
|
| Date Last Visited |
06-08-2026
07:43 AM
|