Iwas facing the same issue while deploying artifact to tomcat with jenkins via container plugin,Solution:- i have added manager-script and manager-gui in the roles of the user and provide the full access to webapps/* directory. It helps me to deploy the artifact successfully and able to view it with manager-app.
You need to update : /webapps/manager/META-INF/context.xml. Because it allows only localhost. If you know the specific hostname or IP, you can add it replacing XXX.XXX.XXX.XXX by the IP address.It's realy important to keep the security in place.
In Tomcat 9, you don't need to add any manager-XXX roles. All you have to do is add the users and and assign the manager-gui (for GUI access) and manager-script (for access like Jenkins deployment ).Also, make sure to edit the file /webapps/manager/META-INF/context.xml, either to comment out valve or define appropriate reg ex for allow attribute
We going to be upgrading from ArcGIS 10.5.1 to 10.6. We use concurrent licensing. My first step was to upgrade our license server from 10.5.1 to 10.6. Now ArcGIS 10.5.1 and later ArcGIS 10.6 give the following error:
Downgrading back to license server 10.5.1 still yielded the same error from ArcGIS 10.5.1. I have upgraded the license server to 2018.1 (10.6.1) and I still get this error. I have deactivated all my licenses, uninstalled the license server completely and reinstalled and still get the error. My server firewall is open on the correct ports to all applications because there are other FlexLM licenses hosted on this server and the ports are not pointed to a specific license server program. The weirdest thing is that users are able to borrow licenses with no problem. While this is a temporary fix, I cannot have the licenses borrowed from the server because ArcGIS is loaded in a classroom lab and in a lab in our library so students can access ArcGIS outside of class to finish homework and class projects.
The error usually indicates something has changed in the service.txt file. How this may have happen, I cannot say. The easier and cleaner option is to uninstall the ArcGIS License Manager. Before doing so, go to C:\Program files (x86)\ArcGIS\License10.6\bin. Copy or move service.txt to another location. Uninstall the license manager. Make sure service.txt was removed. Reinstall the license manager should create a new service.txt file. Make sure the license manager and function properly. Give this a try.
The bug from ArcGIS LM 10.5.1 corrupted the service.txt file. The diagnostic tool in ArcGIS License Manager 2018.0 reads and display the correct features licensed but ArcGIS Pro does not display license counts correctly and users can't interact with it e.g. can't select Extensions.
Can you provide more information? There's not enough detail here to determine what is happening. You mentioned LM 10.5.1 bug but using LM 2018.0. I'm assuming you're using LM 2018.0. Can you go to the Availability folder so we can determine what license was authorized? Also go to the Configure Authorization dialogue in ArcGIS Pro. Make sure it's pointing to the correct license manager. It's possible you're pointing to the wrong license manager.
I read on this GeoNet community that a bug with a previous version of License Manager i.e. ArcGIS License Manager 10.5.1 had a bug which affected the service.txt file resulting in the error I see when attempting to view licensing in ArcGIS Pro while ArcGIS Administrator will correctly display the complete and correct licenses for ArcMap. I also get a little graphic when Arc Pro is open which warns about lost license see graphics below).
Thanks for the explanation. The bug you've mentioned concerned the FEATURE ACT line in the service.txt file. When authorizing named user licenses, it did not update the FEATRURE ACT line. This was fixed in the next version. If you experience the issue and just upgraded your license manager, you will still have the issue. Do the following to resolve it:
Thank you very much for your suggestion and advice. On my par,t I must apologize again for not explaining my predicament more fully. We use Concurrent licenses for ArcGIS Pro. We had converted from Named User to Concurrent, and for some reason the Named User feature items in the license were not removed after the Concurrent licenses were added, perhaps because of the previous LM bug?. Also, we have no So we have entries such as these which appear when listed through lmutil and the diagnostic tool in LM 2018.0 :
1. Reinstall the license manager. Uninstall the license manager. Rename or remove service.txt from C:\Program Files (x86)\ArcGIS\LicenseManager\bin. Install the license manager will create a new default service.txt. All your Concurrent Use licenses will still be authorized.
2. Manually edit the current service.txt file. Remove all the INCREMENT lines. These are listings of the named user licenses you've authorized. Leave just the following. Save and reread the license file or restart the license manager.
In this case, the FEATURE ACT line must be the same as the original before authorizing the named user license. Open service.txt.old file in the same directory. If it has not be updated and no named use license is present. The content of the FEATURE ACT line should be different from the current service.txt file. Replace the FEATURE ACT line or just replace the current service.txt with service.txt.old.
Amnoy, I submitted a ticket with Technical Support and they provided a replacement service.txt. I replaced the corrupted file with it which fixed the Pro Licensing panel interface functionality and display.
This same issue is present in the new ArcGIS License Manager 2019.0 software provided with ArcGIS Desktop 10.7.1. If your ACT feature shows 'Users of ACT: (Error: 1 licenses, unsupported by licensed server)' then your license counts will be incorrect and ArcGIS Pro will give the error previously described while in operation.
I recently installed Java 9.4 on several machines for my work group.
Of course the install went fine on all but my primary desktop where I need SAS to work the most. It was a wonky install from the beginning and I had to make several attempts before it made it all the way throught.
(5)
I'm not certain any of the suggestions in 9.3 notes will fix my 9.4 installations since 48548 says 9.4 is using a "privatejre".
I am not a networking person or particularly good at diagnosing these sorts of problems. It's frustrating that the install went fine on other machines, but at least that indicates that the installation disks are okay.
Please note that I indicated in my response that I was able to fix my problem without having to re-install SAS based on . I posted my response in this thread since I thought it would be useful for others to know that a re-install of SAS might not be necessary to address this problem.
SAS in my limited experience is picky about the version of Java. Your original config file should point to a workable version. If that is no longer on the machine you may need to reinstall the old version.
I'm not sure what the problem was. A simple uninstall/reinstall through the deployment manager was not sufficient so I went witha a kitchen sink approach.
So I did another uninstall using the deployment manager so that it would tell me no version of SAS was on the machine. I reviewed the installed programs via the control panal, where I found SAS and other items were still listed. The windows program manager would not uninstall them or delist them. So, I found and deleted the SAS 9.4 directories manually, went back to the control panal which agreed to delist them at that point. For good measure I uninstalled JAVA using the control panal.
I was at first extremely concerned, seeing a username that was most certainly NOT my own and the strange folder name. Also it was clearly trying to interact with my core system files, which was worrying from some unknown source.
I wanted to report this both so that Intel can be aware of and perhaps fix this accidental log file generation on end users' systems -- I don't know if there are any security concerns here, if we are maybe seeing a username and folder structure from one of your developers? -- and I also hope that anyone else worried about this strange text file may stumble upon this thread and get some answers.
For what it's worth, I am using Windows 11, and I was experiencing issues with EVERYTHING i tried to install when this happened, so that includes the driver update. I don't know how it happened,. but my msiexec AKA windows installer service was broken. No matter what I tried to install, the install wizard would just freeze and do absolutely nothing no matter how long I waited. No errors, just...nothing. I tried every bit of troubleshooting I could find trying to fix it, but ultimately had to completely reinstall Windows to be able to install applications again.
I recommend you check with Microsoft to confirm if there are any reports from their side. Since the issue was fixed after the Windows reinstallation, let me know if you would like to close this thread.
Although I am not affected by this, it only took a few minutes to collect this information. I am appalled that this situation has been posted for two weeks, and there is no mention or confirmation from Intel that the strings reported by the various forum users have been investigated any further.
3a8082e126