Windows 2019, SAS 9.4M7, VA 7.5 We're looking to initialise the Service Architecture Framework in our environment (for some reason this wasn't done on installation), as documented here: Initializing and Enabling the Service Architecture  When running validate.bat --level 2 in config/Lev1/Web/SASEnvironmentManager/emi-framework/bin I always get the response as follows: Starting level 1 validation... Level 1 validation completed with 0 error(s) Starting extended level 2 validation (this could take a while)... Service Architecture validation completed with 1 error(s) Errors: 1) The SAS Environment Manager Server is unable to process additional tasks at this time. This may be due to high change request volume. If the server has recently been (re)started, it may be synchronizing with its Agents. This process could take up to an hour. Please try again at a later time to validate your environment. It doesn't matter when I try this, and how busy (or otherwise) the server is. It produces a couple of log files but there doesn't seem to be anything else useful in them (see attached). Does anyone have any insights? Thanks. ... View more

SAS 9.4M7 on Windows server 2019 Enterprise Guide 8.3 on Windows 10 SAS Studio 3.81 Enterprise Edition   We are having problems enabling users to pull Open Street Map mapping into PROC SGMAP output. By default servers in our environment do not have direct access to the public internet, so we have rules on the proxy servers to allow access by our SAS servers to the SAS OSM servers. This was actually set up to allow geomapping in Visual Analytics (and that works fine). But what we're finding is that this fails for ordinary users, but not for user accounts which are configured for server admin - these are in a different active directory container. I don't have much understanding of how proxies work but here's the analysis from our proxy admins:   When a user attempts to load a map using PROC SGMAP, the map is not rendered in the client. On inspecting the traffic on the SAS server using wireshark during the failure, the following behaviour is noted :-   The SAS server issues DNS lookup requests to its OS configured name servers for opnsta.sas.com and gets a no such name response. The name servers are internal and cannot perform public DNS resolution. This is by design and a security configuration. Hence if an internal resource needs to connect to an internet website, it must use a secure proxy server. After the first DNS answer, it then performs a DNS query for the server which hosts the PAC file from our internal DNS server and gets a valid response. It downloads the PAC file. Whilst it is downloading the PAC file it sends two further DNS lookups to internal DNS for opnstc.sas.com and then openstb.sas.com which both return no such name.   It then connects to the proxy server gleaned from the PAC file. However it does not parse these correctly. The PAC file is configured to return back to the requesting application PROXY name.of.our.proxy:portnumber (i.e. use this as a proxy server). But the application appears to receive the PROXY name.of.our.proxy:portnumber returned and then tries to connect to it as a webserver which fails as it isn't one. It should be noted that the admin users (for whom the functionality works) don't have a PAC file configuration and so calls are directed straight to the proxy server. Has anyone had a similar experience, and did you find a resolution? I haven't had much luck with TS, because they say that there's no configuration options for PROC SGMAP and it just sends a straight call to the internet.   Thanks   ... View more