For whatever reason I have been getting a failure to publish error when publishing to portal. I can publish to AGOL just fine. I've been on numerous calls with Esri customer service as well as pulling in outside sql help to play around and look for what may be the problem. No one can find anything. A waste to pay this much money and not be able to use the service.
You may need to put your ArcGIS Server into a higher level of debugging. Warning/Severe may not help. Then work through the steps here:
https://support.esri.com/en/technical-article/000016577
to try and see what logs are being generated. That's probably the best way to give us some insight. Using DB users certainly rules a number of things out which is good.
Yup - that tells me the same as what you have put into words. The bottom error starts to tell me what the problem, but then the screen grab cuts it off. It's almost like a "We'll be right back after this commercial break". Also, the logs are 'severe'. We may need more detail than that, the verbose/info level of logging may give use some indications. It would be interesting if you could also send the details of the data store configuration. I've previously seen people use slightly different parameters between the publishing connection and the data store, and it is enough to cause issues like this.
First things first, give me a better view of the last log message in that image and the corresponding configuration settings in the Server's Data Store page.
In the Data Store, you will have added the configuration of the SQL Server database so that ArcGIS Server can 'validate'. I need to know what is in there to make sure it's the same as the information in the above screengrab. There will be a pencil (edit) icon on the SQL Server entry which will open a window showing the configuration. I need to see that.
In the latest image you've sent I can see the heart of the matter, though. It says 'SwizzleService failed'. The SwizzleService takes your MXD/Pro document and looks at all the connections in it. It says, okay, this is what the user can see when 'they' are working. I now need to make this work for me as the 'ArcGIS Server' so it 'swizzles' the parameters around so that it can work in the same way that you can. That is failing. In essence this means that the ArcGIS Server cannot see what you can see. That could be down to a firewall issue, or a DNS issue. It could be that you and the database are in one IT security zone, but the ArcGIS Server is in another. It's the grey space between GIS and IT. But in essence the ArcGIS Server is trying to speak to your SQL Server and cannot get a response.
Fire though the configuration screenshot for the data store and we'll take a look?
Sorry, you need to expand the publisher database connection. There's not enough information visible.
Sorry,
There are some very slight differences in the connection properties between what you have in the data store configuration and what the logs are telling us. The datastore has the server names in upper case while in the logs it's lowercase. In the datastore we see that the INSTANCE=sde:sqlserver:MCGSSS02.
You've said that this all validates, which is great!
The instance in the logs is using a Instance="DSID=guid" reference instead of the above. I wonder if it cannot resolve to this. Personally, I like things to be 'clean'. I'd create a new data store entry with the same info as the logs (i.e. with the DSID entry) and see if you can get that to validate. That will tell us a bit more then.
An issue here is that a lot of people will use a sde file to create the data store, but then they have variations of that file that they use in different map documents. Sometimes they are close enough that it doesn't get picked up during publishing as a new datastore entry. But there's sufficient differences in there that the publishing will fail.
I was also reminded of another thing, but this only applies if you're using dedicated instances. You may want to try publishing the service with a min instance value of 0. It may publish, you can then try and increase the min instances to 1 (or more) after publishing and see if you can get it to work that way. It was something we did way back when, but may just work....