Showing results for 
Search instead for 
Did you mean: 
Level 5

FAQs and Myths for Storage Foundation Keys

Keys have gotten simpler, but explanations and awareness haven’t kept up

June 16, 2009

To start, let’s review the difference between a license and a key, as the two terms are often (but incorrectly) used interchangeably. A license – a Storage Foundation end user license agreement (EULA) – is a legal contract between Symantec and a customer. An example of a EULA for Storage Foundation Basic is posted here. A Storage Foundation (SF) key is a 23 digit alphanumeric string that unlocks SF software for use, for example ‘A1BC-DE2F-3GHI-JKL4-M5N6-OP7‘. So a license is a legal contract, and a key is a cryptographic string that activates or enables software. Figure 1 further illustrates the situation.
imagebrowser image
SF, VCS and NBU use the same key infrastructure (known as SIG, for ‘Shared Infrastructure Group’) but SIG offers some latitude in specific behaviors, so this article’s scope is limited to Storage Foundation UNIX & Linux keys.

Node locking

Node locking refers to tying a key to a server’s unique hostid, so that the key to unlock SF on one host will not unlock SF on a different host. Node locking was removed from SF a couple of releases back (see Figure 2 for details). Customers using those old versions (and encountering added administration due to node locking) should be aware that current versions of SF are not node locked.
Removing node locks allows for more operational consistency. Using the same key to unlock SF on both ‘server a’ and ‘server b’ increases data center standardization, which is usually desirable. Again, note the distinction between a license and a key. If you do not have a SF license for each server running SF, you (and your employer) are committing software piracy; a license cannot be ‘shared’ among multiple servers. In contrast, the same key can be used on multiple servers to simplify and standardize your operating environment.

Platform enforcement

SF is currently licensed on a per-platform basis, where a platform approximately corresponds to an {operating system, chip architecture} pair. SF keys are specific to a platform, so a Solaris SPARC key will not unlock SF on a Solaris x64 server – nor will it unlock SF on an AIX server. An exception is Linux keys, which work on both RHEL and on SuSE.


On AIX, HP-UX, and Solaris SPARC, SF is licensed for distinct server tiers. Tier 1 maps to entry level servers, and Tier 4 to the largest enterprise machines. Each SF license is only good for the Tier on which it was issued. In contrast, SF keys do not enforce / check for the machine tier. This is partly because the operating systems’ utilities to check server model are not always sufficient, and partly because server tiers are sometimes (albeit rarely) reclassified by Symantec. Note that in the past SF keys did enforce tier.
On Linux, SF is licensed by number of CPUs, not by tier. From SF 4.0 onward, the key does not enforce CPU count; prior versions did. Solaris x64 is also licensed by CPU and current keys do not enforce CPU count.

Product enforcement (e.g., SF vs. SFRAC)

Within the SF and VCS family, Symantec markets several different products. Each product has a distinct combination of features and functionality, and each product is licensed separately. Examples include Storage Foundation, Storage Foundation Enterprise, Storage Foundation HA, Cluster File System, and Storage Foundation for Oracle RAC™. A key unlocks the features and functionality of its corresponding product. It does not unlock the features and functions of other products; in other words, keys do enforce a given product’s features. Mapping features to products is beyond the scope of this article.

Compatibility between Keys and Software (Binary) Versions

Users often ask whether a version x key will work with SF version x+1; and also whether a version x key will work with SF version x-1. To better understand why this works in one direction but not in the other, it helps to understand that the key fits into a software ‘lock’. The lock decodes the key and, using the decoded information, enables functionality in Storage Foundation. The lock ships with and is updated with each new version of Storage Foundation. The lock is compatible with old keys, i.e., keys from prior versions, because the structure of old keys is known. In effect, the lock can be ‘shaped’ so that those old keys ‘fit’ the lock.

In contrast, the structure of new keys is not known in advance; the lock cannot be ‘pre-shaped’ to anticipate what a key might or might not look like in the future. The upshot: older keys can be used with newer software versions, but new keys cannot generally be used with older software versions. There are two caveats.

First, an old key will unlock all the functionality of the product version it maps to, but new features may not be unlocked. From a user perspective, the features you used before the upgrade will continue to work using the old key. However, some new features in the new version may not work until you apply a new key.

Second, a new key may sometimes unlock an old version, but this is neither by intent nor by design. Do not rely on it to work, even if you have seen it work in the past. A full explanation of why it sometimes works would be lengthy, but it centers on adding new features.

Note that the above behavior is the same, even across the ELM-SIG “boundary”. SIG locks, introduced in 2002-2004, replaced the older “ELM” locks which had been used starting with Storage Foundation 2.x. But, to avoid customer disruption, SIG locks recognize and honor ELM keys. See Figure 2 for the version/platform detail when SIG replaced ELM.

Temporary keys

Temp keys unlock a product for a limited time period. Currently, the SF licensing system allows a single 30 day temp key to be installed, plus a single 60 day temp extension, for 90 days of total temp key time. Removing the temp keys does not ‘reset’ this 90 day cumulative limit. This is a change from SF’s old licensing system (ELM), which allowed temp keys to be repeatedly applied in perpetuity. For specific details on SIG and ELM versions, see Figure 2 at the end of this article.

Key Additivity

People occasionally ask if the order of entry, or if specific key combinations, affect what gets unlocked. For example: “If I enter a permanent key first, then later enter a temp key for the same product, will the product stop working when the temp key expires?” or “If I enter a Cluster File System key, and then later enter a VCS key, will CFS stop working because VCS doesn’t enable CFS?”
In this respect, keys are very simple. Keys are only additive, and the order in which keys are entered is irrelevant. Using database terminology, adding keys performs a union function. If an installed key unlocks a given product or feature, it stays unlocked regardless of any other keys added.


Myth #1 – “Only certain customers get Gold Keys.”
In the past, Symantec (then Veritas) supplied some customers with “Gold Keys”. A Gold Key is a key that is not restricted by Tier, and is not node locked (but is still limited by product and by platform). As noted above, SF keys are no longer restricted by tier, and are no longer node locked. So, all SF keys are Gold Keys.

Myth #2 – “Symantec requires you to upgrade your key when upgrading to a new version of SF.”
Customers are not required to upgrade SF keys when upgrading the SF binaries to a new version. As noted above, old SF keys are recognized and accepted by new SF binaries. One benefit of upgrading the key is that it may unlock new features in the new binary. (Old keys rarely unlock new features, for the simple reason that when old keys are created, the new feature’s existence is not known, and thus isn’t coded into the key). Symantec Support may recommend upgrading keys to avoid future confusion over new features not being enabled by a new key.
Note: Upgrading to a new SF version requires a current support contract.

Myth #3 – “You have to remove the old keys / temp keys after installing a new key.”
Symantec does not require that old keys or temp keys be removed from a server. As noted above, keys are additive. So old keys and temp keys can be kept indefinitely. There are pros and cons either way. Keeping old keys eliminates the risk of accidentally removing the wrong key. But keeping old keys also clutters the output of reporting utilities.

imagebrowser image

Level 4
Great article, Scott. I'd also like to point out that VIMS ( and SFM 2.0 with the LDR addon ( can help you get a handle on your installed keys.
Level 3

Thanks Scott!

Is this a myth: I have heard that Symantec is getting rid of keys altogether.

Level 5
Now that Storage Foundation 5.1 has gone live, I can answer Simon’s question directly. 5.1 gives users a choice. Option 1: continue to use exactly the same key process/model as 5.0, 4.1, etc. Option 2: use 5.1’s new ‘keyless’ process/model. You can learn more about that model here:
Level 2
Scott -

Thanks for the informative post.

Can you offer any suggestions for untangling the 'tiering' connundrum?  I understand this information is not publicly available, yet in order to be compliant with Symantec's licensing requirements, we need access to it.

For instance, I have hardware that's being re-purposed.  Some boxes that were running SF products aren't any longer, and some that weren't will inherit the available licensing.  Problem is I can't tell where I can move these licenses without the tiering definition. 

I can understand that it's information that Symantec would want to keep close to the chest in terms of pricing, but do the tiers change, too?  I mean, couldn't we have a "priceless" tiering document?

Thanks for whatever info you can provide.

Level 3
Partner Accredited
Please what do I do if I want to renew license on a Sunfire E25k with three Domains. The Domains have been upgraded from Veritas SF 4.1 to 5.0, but the License needs to be renewed for support.
The License has been paid for already.
Please I need the steps/command required to achieve this.

Level 5

You can work with your Symantec account team or reseller; they should be able to help.

Another alternative is to run a Product & License Inventory report using VOS (soon to be renamed SORT). That report includes the tier of each server.


You can see a sample of what such a report looks like here:

Level 2
Employee Accredited Certified

Really useful article.  Is there an updated version? I'm sure nothing much has changed but it would be nice to have a newer version which includes v6 and it may be helpful to add a line explaining how customers who wish to run an older version, but can only get new licence keys, can get them so that we can, from one blog/article, get all the information we need.

Many Thanks



Version history
Last update:
‎06-17-2009 09:17 AM
Updated by: