Wow, 18 replies. I really appreciate all the information, folks. I've already read some of the resources out there on KMS and MAK, but it seems I managed to overlook the more important technical ones. I'll have a gander - thanks again.
-- Brian Cline ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harvey Kamangwitz Sent: Wednesday 06 December 2006 00:41 To: [email protected] Subject: Re: [ActiveDir] OT: Vista Activation and KMS On 12/5/06, Laura A. Robinson <[EMAIL PROTECTED]> wrote: Inline... ________________________________ From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Harvey Kamangwitz Sent: Tuesday, December 05, 2006 11:28 AM To: [email protected] Subject: Re: [ActiveDir] OT: Vista Activation and KMS If you have any kind of a complex environment, you'll find volume activation to be very frustrating indeed: 1. The KMS service can't support more than one key, so if you have Longhorn VL clients in your environment you have to put up a second KMS infrastructure for them. Actually, when you purchase a KMS key, you get to activate TWO KMS hosts with that key, up to ten times each. Therefore, you don't have to put up a second KMS infrastructure. >From a subsequent post on this thread: Doh! Okay, now I think I get what you're referencing in item 1. There's a reason for that- LH isn't out yet. When LH is out, that won't be an issue. :-) My hope was that KMS could support more than one key. I was astonished when I discovered it didn't. If you were Vista, KMS would supply you with a Vista key. Longhorn, a Longhorn key. Since KMS only supports one key, it triggers the need for two separate KMS infrastructures and the problems in #2 below. I'm assuming that Microsoft will be using Volume Activation for other products in the future; are we to put up a separate KMS for each? 2. You can't (rather, shouldn't) use autodiscovery If you do have both LH and Vista. The KMS client can't distinguish between a KMS with LH and a KMS with Vista, and there's nothing in the client that says "oh, I hit a KMS but it has the wrong key so try again immediately" so ~50% of a client's activation attempts will fail. So remove the DNS records for the LH KMS, or am I misunderstanding your point? To be more specific: In a Vista / Longhorn environment, you should only use autodiscovery for one KMS infrastructure because of 50% failure rate above. The other systems (Longhorn, if you choose autodiscovery for Vista) must be explictly pointed to a KMS with slmgr. How much of an adminstrative headache this is depends on how great a penetration of a standard build is in your company; you can code it into the build. 3. Autodiscovery isn't practical if you have more than a few forests that don't trust the forest your KMS is in. All admins of the untrusted forests must manually register the _vlmcs record in their forest to find the KMS. slmgr.vbs. We're not talking about a ton of records here or a difficult population mechanism. It's the logistics and overhead that's a pain. No, the act of registering a _vlmcs record in a domain is not in itself a difficult task; it's the help desk scripts and calls from panicky system administrators when all the clients in their forest start complaining about "failure to activate" and "reduced functionality mode" that have to be handled. In a large enterprise we could see a lot of these (everyone that brings up a sandbox forest for application testing, for example). I'm attempting to design a solution that minimizes the impact for everybody - corporate forest administrators, Vista users, help desk, untrusted test forest administrators, etc. ...the list goes on. (I haven't even mentioned the practical aspects of volume activation in a lab or firewalled environment.) I'd be happy to discuss your options around them if you should decide to elaborate further. If the firewalled labs don't want to open port 1688 to find a KMS, they either have to bring up their own KMS or use MAKs. I for one don't want to hand out KMS / volume keys to anyone outside the corporate KMS infrastructure. And MAKs, though I haven't studied them as closely, are a pain for labs that rebuild their clients because they're a single-use item (by which I mean that if you use up one activation count on a MAK then rebuild, it increments the MAK count - you can't reuse the previous one). And they still require some kind of internet access, or by proxy, or by phone, to activate them. It's not a fully-baked solution. I would tend to disagree. From a technical standpoint, I think it's pretty well-baked. From a business process standpoint, it's still coming up to speed. Depending on your environment, it might be easier to scrap the whole autodiscovery, create a DNS CNAME with a couple of KMS behind it, stuff the FQDN in the KMS client's registry if you have a standard build, and fugeddaboutit :-). I'm not really understanding your concerns about autodiscovery. Could you be more specific about your environment? - Autodiscovery is no problem for Vista clients in the corporate (account) forest; that's where the KMS service is. - Not much more problem for clients in major (top tier) trusted forests. - Begins to be overhead for corp forest admins when you start adding 2nd and 3rd tier trusted forests into the KMS autodiscovery registry key (who can really keep track of what's active and what's died on the vine; do they ever tell US they've shut down their forest?). - Is overhead for untrusted forests that come and go because they must figure out or be told what to do when they call the help desk in a panic because their Vista clients are threatening RFM. They can't autodiscover the corporate KMS because the client autodiscovery only looks in his own domain, and the KMS servers can't register themselves in DNS zone in a forest that doesn't trust them. - Is overhead for Vista clients anywhere in the network that aren't part of the corp forest or one of its trusting forests. They'll fail because autodiscover can't find a KMS. Same applies for 99% of firewalled networks because they most likely don't have a DC from the corp or trusting forests in their network and therefore autodiscover will fail. So what you have if you try to use autodiscovery in a large enterprise is a bunch of little problems requiring a bunch of solutions (and a lot of help desk scripts). If you have good penetration of a standard IT build, point them all to one place and be done with it. <soapbox> It grinds me to no end that the only KMS platform to support an enterprise-wide Vista rollout is a Vista client. How many enterprises are set up to provide server services on a brand-new client OS? None that I've talked to. Yes, it will soon be piloted on W2K3 (there's a Livemeeting on it tomorrow morning); that was in response to a chorus of TAP member complaints in the Vista and Longhorn betas. Until a couple of weeks ago we all understood KMS for Vista could at least be run on Longhorn server; I was in the room with the development team and no one disabused me of this notion. Then it changed. Why couldn't there have been a supportable server platform for this when the product was released? </soapbox> We are (unwillingly) running KMS on a Vista client until the W2K3 KMS proves itself to be reliable, then we'll switch over to it. All hidden behind some generic DNS alias. -Harvey Laura On 12/4/06, Laura A. Robinson <[EMAIL PROTECTED] > wrote: KMS runs on Vista (now), will run on Longhorn when Longhorn is released, and will also run on Win2K3 as soon as we finish making the Win2K3 install. :-) Laura > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] On Behalf Of > Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] > Sent: Monday, December 04, 2006 1:12 PM > To: [email protected] > Subject: Re: [ActiveDir] OT: Vista Activation and KMS > > Nope, I've done it web based. At the present time there are > two kinds of keycodes up on MVLS.. one that wants a KMS, the > other that will phone home to Redmond automatically. > > Have your MVLS folks request the other type of key is my > understanding how this will work for now. The KMS type won't > be out until Longhorn. > > KMS activations will have to phone home to your servers twice a year. > > Brian Cline wrote: > > > > I was testing out the RTM of Vista Enterprise last night > and noticed I > > didn't have to enter a key at any point during the install. When > > Windows tried to activate, it told me there was a DNS error, so I > > suspected it looks for a local activation server by default. Sure > > enough, in the DNS cache was a lookup for a nonexistent > > _vlmcs._tcp.domain.com. Upon further research, it appears Microsoft > > has not released KMS yet, and I couldn't find any option to > activate > > directly with Microsoft. For the moment, is telephone > activation the > > only option? > > > > Brian Cline, Applications Developer > > Department of Information Technology > > G&P Trucking Company, Inc. > > 803.936.8595 Direct Line > > 800.922.1147 Toll-Free (x8595) > > 803.739.1176 Fax > > > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com <http://www.threatcode.com/> > > If you are a SBSer and you don't subscribe to the SBS Blog... > man ... I will hunt you down... > http://blogs.technet.com/sbs > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/[email protected]/ > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.430 / Virus Database: 268.15.6/567 - Release > Date: 12/4/2006 7:18 AM > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 12/4/2006 7:18 AM List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/[email protected]/ -- S. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.9/571 - Release Date: 12/5/2006 11:50 AM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.9/571 - Release Date: 12/5/2006 11:50 AM
