I'm curious about how often images are actually shared among organizations. I would imagine it is somewhat frequent for base images, but fairly seldom for any other images. If that's the case, we could probably stick with image owner activation.
I'm pulling in the user@ list to get more feedback on how much people are sharing images among different organizations using a single VCL install. Josh On Mon February 15 2016 11:34:42 AM Andy Kurth wrote: > 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 -- ------------------------------- Josh Thompson Systems Programmer Virtual Computing Lab (VCL) North Carolina State University [email protected] 919-515-5323 my GPG/PGP key can be found at www.keyserver.net All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
signature.asc
Description: This is a digitally signed message part.
