I'd like to get the VCL dev community's thoughts regarding how the code that activates Windows images (Vista, 7, & later) selects which KMS server or MAK key to use. Also, I'd like to figure out when, if ever, a previously activated computer should be reconfigured to use another organization's activation information.
When VCL captures a Windows image, it deactivates or "rearms" the computer's activation status prior to the capture. This is done to remove all activation information prior to capture such as a KMS server address in order to help preserve the integrity of the license, preserve the security of an organization's activation infrastructure, and to prevent unauthorized used of a license. There are also some technical reasons for rearming in order to prevent problems when an image is loaded long after it was captured. When the image is later loaded, VCL attempts to activate Windows by using the address of a KMS server or a MAK key stored in the database. Each KMS server or MAK key stored in the VCL database is associated with an affiliation. A stock installation of VCL only includes user accounts belonging to the "local" affiliation such as the built-in "admin" account. Most deployments of VCL add additional affiliations so that external authentication mechanisms such as LDAP can be used. It is fairly common for a single deployment to be shared by multiple organizations. In this scenario, a separate affiliation would be added to VCL for each organization. Currently, the VCL code uses the affiliation of the user who owns the image in order to determine which KMS server or MAK key to use. If an image owned by organization A is shared with users from organization B, the KMS or MAK configured for A would be used even though the reservations are made by users from B. I'm debating whether it would be more appropriate to select the affiliation based on the reservation user's affiliation rather than the image owner. If so, how to accomplish this without harming load times. Why not just use the reservation user's affiliation? I originally wrote the activation code and the rationale for using the image owner rather than the reservation user's affiliation is because a computer reload process is not always tied to a user's reservation. As you probably know, VCL automatically reloads (or pre-loads) a computer with an image after a reservation ends whether or not that computer is assigned to another user reservation. When this reload process occurs, there is no end user information associated/available to the reload process. The next closest piece of user information the code has access to is the image owner. Why not just skip activation when a computer is reloaded, but only activate it when the computer is reserved for a user? To reduce load time. The commands required to activate Windows take by far the longest of all of the commands VCL performs after a computer boots. In most circumstances, if a computer pre-loaded with an image it only takes 30 seconds or less to perform all of the steps necessary for the connect button to appear for the user (create user, set password, configure firewall, etc.). Each activation command may take 5-15 seconds to complete and a minimum of 2 commands is required to activate. Activating Windows during this phase could easily double the time required for the connect button to appear. We could look at a hybrid solution, where an image is activated when pre-loaded based on the image owner's affiliation. When a pre-loaded image is reserved, the code could check if the image owner and reservation user belong to the same affiliation. If the affiliations differ and are configured to use different activation information, the code could deactivate and attempt to reactivate. This would be extremely slow. Not only would it take several sluggish commands to complete, I believe it would also require a reboot in order to be done properly. This would also introduce another issue. If a computer is deactivated/reactivated using a user's affiliation but that user never connects to the reservation, the reservation would timeout and the computer would be put back into the "available" state poised for another reservation. When another reservation is assigned to that pre-loaded computer, the VCL process wouldn't easily/quickly know which affiliation's information was used for activation. Sure, a command can be executed to retrieve the current activation information from the computer for every reservation but I want to avoid this because the retrieval command is slow. We obviously will do whatever is necessary to ensure that VCL is 100% compliant regarding all aspects of licensing. There are, however, details which can be ambiguous or confusing. So, the ultimate questions are: What is acceptable from a licensing perspective? How can we implement a 100% compliant solution without negatively affecting load times and the end users' experience? I'd greatly appreciate any knowledge or ideas others can share. Thanks, Andy
