As I understand it, the SU variant of the software is what's installed when you download from this page:

http://www.intersystems.com/library/software-downloads/

And as your error message states, this variant is barred from using a cache.key file to unlock further features.

I think you'll need a different software kit. AFAIK you'll be able to "upgrade" your current SU installation in situ without losing anything (provided you've followed the rules about how to name any of your own code that you store in %SYS).

Those of us with support accounts can download software kits via WRC Direct. But assuming you don't have such an account yet, the InterSystems folk who provided you with the evaluation key are probably the best ones to ask about how to get hold of the software kit you need.

Have you considered implementing a Caché source code management tool such as Deltanji from George James Software, for whom I work? A Deltanji workflow can propagate code from one namespace to another, and can also propagate deletions. In other words, if you decommission a class in DEV, then propagate the now-decommissioned code object to TEST, the class will be deleted from TEST.

If you don't mind working a the global level, here's a way of enumerating the classes that are stored in the default code database of a namespace:

USER>s namespace="%SYS"                                                          
USER>s impliedNamespace="^"_##class(%SYS.Namespace).GetGlobalDest(namespace,"^oddDEF")
 
USER>w impliedNamespace
^^c:\intersystems\ens171\mgr\
USER>s className="" f  s className=$o(^|impliedNamespace|oddDEF(className)) q:className=""  w !,className

The page at https://download.intersystems.com/download/atelier.csp tells you how you can obtain the 1.1 beta provided you are using Atelier as an Eclipse plugin rather than as a standalone Eclipse-based application.

I don't know if the current 1.1 beta fixes this issue, nor if it will require a version of Caché greater that the current 2017.1 release in order to solve it (or indeed to work at all).

Settings stored in the XData block of the production class (e.g. values entered through Portal) trump any System Default Settins values.

In Portal there's this button to get you to a page that may help you understand what's going on:

For a long time I've complained that the Portal UI makes it too easy to override a System Default Settings value (which is namespace-specific) with a value that gets stored in the production class (which you might migrate from one namespace to another). Add to this the fact that Portal ignores source control when altering the production class sad

Here's the base implementation of this method in %Library.GlobalIdentifier (2017.1 version):

 /// If a persistent class is GUIDENABLED then this method can be called to override the default GUID assignment.
/// This method accepts a guid value and returns the override value currently assigned. The return value will only
/// differ from the supplied value if the override is unsuccessful. It is only valid to call this method on a new object.
/// The guid value passed to this method is not validated. It is up to the user to make sure the guid is properly formed.
/// The guid assignment does not actually occur until the object is saved. If the object has already been assigned a GUID
/// or if the GUID override value has already been assigned to another object then the GUID override value will be discarded.
/// The check for GUID value uniqueness and a GUID value previously assigned is done only at the time the object is saved and is
/// not performed by this method.
Method %OverrideGuidAssignment(pGUID As %Library.CacheString) As %Library.CacheString
{
set i%"%%GUID" = pGUID
quit i%"%%GUID"
}

If I understand Alex correctly, he's calling this method in order to force a new instance of a GUIDENABLED class to have a specific GUID instead of getting one automatically assigned at save. He's not overriding the class in his own class definition.

I have highlighted in yellow some sentences in the comment that may be relevant.

I have also highlighted in pink the sentence Alex quoted, which is a bit unclear. By "return value" I think it means the GUID of the object instance after the save has subsequently been performed.

Unless you upgrade to 2016.2 or beyond you can't yet use Atelier as your code editor, so integration with file-based source code management (SCM) tools such as Git or Perforce isn't so straightforward. Deltanji works natively inside Caché 2008.1 and later and integrates easily with Studio (as well as with Atelier). The Solo edition is free.

Or maybe when you write "Configuration management tools" you aren't referring to SCM?