This piqued my interest because I had always thought that SAS metadata object id's could not be changed once assigned. I was surprised that metabrowse would allow you to attempt to change the id. To see what it was trying to do I repeated your example with trace level logging turned on for the metadata server with a throwaway sandpit environment. This was the metadata API XML request it sent to the metadata server with the same error that you saw:   2018-09-11T10:22:20,525 TRACE [00402070] 1020:sasadm@saspw - IOM CALL {compRef:7f80cc0878c0}->OMI::DoRequest(): inString=<UpdateMetadata><Metadata><AccessControlTemplate Id="A5XNT08Y.AO000006" Id="A5XNT08Y.AO000XX6"/></Metadata><Ns>SAS</Ns><Flags>268435456</Flags><Options/></UpdateMetadata> 2018-09-11T10:22:20,525 INFO [00402070] 1020:sasadm@saspw - DoRequest return code=807fd80b.... 2018-09-11T10:22:20,525 ERROR [00402070] 1020:sasadm@saspw - The attribute name is duplicated in element definition.   You can see from the XML that the duplicate attribute name in question is Id. It is being provided once to refer to the object and again to attempt to change the attribute value ... but that XML is invalid. I wonder if this may be a defect in metabrowse in allowing and attempting a change of metadata object id. You may want to follow up with SAS technical support to check this.   I think you are likely to run into difficulties with a business process based on being able to choose a specific metadata object id and may want to take a step back and revisit the core issue. I think looking at backup/restore options might give you a better outcome.   Looking at the documentation for the Id attribute on the Root object in the SAS 9.4 Metadata Model: Reference, it states in part: Id is a 17-character string that is guaranteed to be unique for a given object within a metadata server. It takes the form of A0000001.A0000001 where the first 8 characters represent the repository Id and the second 8 characters represent the object Id. If the object is a repository, the first 8 characters represent the repository manager and will always be equal to A0000001; the second eight characters represent the repository Id.   Ids should never be stored outside of the metadata object and it should not be assumed that a given logical entity will retain the same metadata Id during its lifetime. When updating logical entities in the metadata server, applications often delete and re-create objects in the metadata server. The new objects created will have different metadata Ids than the original. Also, metadata definitions may be exported and deployed to a new metadata server. These, too, will have different metadata ids than the original objects.   There is also a caution in the SAS 9.4 Open Metadata Interface: Reference and Usage section on Identifying Metadata: CAUTION: Do not attempt to assign Id values in a client application. Let the SAS Metadata Server assign identifiers to new objects.   I have also been thinking that if you were able to modify metadata objects ids you would probably also have to check to make sure the id you are going to use/reuse is not already being used/reused. Also adding an object with the same id as a previous object will not re-instate any associations that the old object had as those associations (and possibly other objects) will have been deleted when the old object was deleted.   Given the use case is someone accidentally deleting an object that may potentially have many other objects associated with it, I would suggest looking into backup/restore options as alternatives. The larger scale options (more disruptive and having potential for loss of metadata changes since the restore point) would be the SAS Metadata Server Backup and Recovery Facility and Deployment Backup and Recovery Tool. For smaller scale options where admins and developers can interactively backup/restore selectively via SAS packages, with the possibility for scheduling package exports in batch, you could look at the SAS metadata Promotion Tools.   I hope this helps. Perhaps, other admins managing large DI environments might offer some suggestions on how they handle this use case. ... View more

The SAS MC log you posted looks like it is missing some of the required JAR files. If rebuilding the VJR cache doesn't resolve the issue then I would suggest uninstalling/reinstalling SAS MC on that client (perhaps there were issues during the install or something has been deleted subsequently?). Otherwise your best bet would be to contact SAS Technical Support. ... View more

Increasing the sas-viya-all-services timeout, as you did, worked for me when I deployed SAS Viya 3.2 - as described at https://platformadmin.com/blogs/paul/2017/04/nudging-sas-viya-services/   However, when I recently deployed SAS Viya 3.4 I noticed that there is now a prerequisite step to increase the default timeout for all services (also documented for SAS Viya 3.3). For more info see SAS® Viya® 3.4 for Linux: Deployment Guide > Pre-installation Tasks > Perform Linux Tuning > Change the Default Time-outs. After making those changes I would stop all SAS Viya services, confirm there are no more SAS processes running and then re-start them.   Before doing that, I would also recommend looking at the logs for the services that failed to start (sas-viya-authorization-default, sas-viya-identities-default, sas-viya-saslogon-default etc.) to see if there are clues as to why they failed to start. ... View more

I wrote a blog post about this that may help you: SAS Management Console on HiDPI Windows 10 ... View more