Yes, SCCM (and, in the future, Intune) is worth it for us as we have upwards of 300 users. But even with admin rights downloading hotfixes directly won't work because of firewall/proxy policies which prevent the download of executables (we have an extremely risk-averse Cyber Security Branch). We have to use a "staging server" in our extranet and then pull them directly from that to a location on our corporate network. And we don't upgrade the clients unless we are doing so to our main platforms, and so get a new software depot. ... View more

We had this problem too, and our Cyber folk won't sanction that extra access required. The approach we have is as follows: Our desktop software (EG and AMO) is installed via SCCM packages running the standalone installations All the latest hotfixes are downloaded to the Software Depot. Another SCCM package has been created which runs SAS Deployment Manager with a response file to apply hotfixes. The important parts of the response file are: MANAGE_TASK=applyhotfix HOTFIX_PACKAGE_DIR=<full path to hotfix dir in the depot> HOTFIX_INSTALL=yes HOTFIX_CONFIGURE=no The package is configured so it can be installed or reinstalled at any time by the user, using the Windows Software Centre. So any time there are relevant hotfixes downloaded to the depot, users can just be asked to run the hotfix package in Software Centre. Is that a method you could use? ... View more

Thank you @Eddie305 that's what I needed! I'd been looking at this section: SAS Help Center: SAS Migration Utility Reference ... View more

I've got both the SMU and the JRE. It's just that the SMU isn't finding the JRE and I can't work out how to get it to do that. ... View more

According to the download page it requires Java 11, which is what we have in the Private Java Runtime Environment: SAS Downloads: SAS 9.4 M8 Migration Utility ... View more

It could be Powershell that's blocked, it is in our environment. Also, we aren't able to download executables in our main environment either. We have to use a dedicated "staging" server in our extranet to download hotfixes which means: Copying the DeploymentRegistry files to the staging server (via another dedicated server which has access through the firewall to it). Run SASHFADD, and the download script, on the staging server. Virus scan the downloaded hotfixes Copy the hotfixes back to our main corporate environment using the permitted server. ... View more

@ecruz1989 I wouldn't have liked to attempt it on our own as it was far from straightforward, so we contracted SAS to do the upgrade. I can't remember the overall number of hours they quoted was, but the actual technical work was considerably less than 160 hours even accounting for the complications we encountered. We were responsible for backups, which was reasonable. In our case this was taking snapshots as the servers are VMs.  ... View more

@ecruz1989 That seems reasonable to me. We did exactly the same thing (for more or less the same reasons) with our four Windows-based servers. We had to have a couple of goes at it but that was due to an existing problem in the M7 installation. ... View more

Here's an example entry from our metadata logs (suitably edited):   2025-01-09T16:36:16,945 INFO [31155358] 1567886:zzzzzzz@Dddddddd - Audit Public Object Type=User Name=XXXXXXXXXX ObjId=OOOOOOOO.AAAAAAA has been delete ... View more

I think this could be a case for Tech. Support. We've had problems with the cache locator before and they've always been able to resolve them. ... View more

It's a few years old but I think this probably answers your question: Solved: I have a user asking if SAS 9.4 m7 will run on a Surface Pro X, with a... - SAS Support Communities ... View more

I don't think you'll get the scheduled jobs from the metadata logs, only entries where people are logging in to the metadata server (and filtering on "APPNAME=SASManagementConsole" will give you the users who have done this with SMC). I see from a later reply that you're using Operating System Services as your scheduler so for scheduled tasks you'd maybe need to look at logs within <config>/Lev1/SchedulingServer. In Windows there's a directory structure here of <username>\<jobname> with logs created by the job's VB Script. I don't know if that helps? Or, the actual SAS programs run under the Batch Server, so there are SAS logs in <config>/Lev1/SASApp/BatchServer/Logs. Alternatively, I'm not knowledgeable enough about Unix to know if there are logs created by cron? Might be entries in syslog? ... View more

You can't view the logs from SMC. You have to log onto the server(s) to do so. For the metadata server logs, these will commonly be in <config>/Levx/SASMeta/MetadataServer/Logs on the metadata server and for the object spawner logs, <config>/Levx/ObjectSpawner/Logs on the compute server.   When @LinusH asks about the scheduler, SMC is only the front end to this. Behind the scenes it will be relying on specific scheduling software. It could be Platform Suite for SAS if you have that licensed or the operating system scheduler on your servers (ie. cron on Unix or Linux, or the Task Scheduler on Windows). Here's where you set that in SMC:   ... View more

For SMC check the metadata server logs. Look for entries with "APPNAME=SASManagementConsole " For EG users I don't think the metadata logs will tell you if an actual SAS session has been started, only if they've connected to the metadata. You could get active users from the Object Spawner logs (that's what I do). ... View more