"If a Vista KMS client contacts a beta KMS host, the client will receive
an "invalid version" error and will proceed to try another KMS from the list
provided by DNS."
This is good information, Rich; I hadn't seen this before. It means that
beta and production KMS infrastructures can coexist. Thanks for posting.
- Harvey
On 12/12/06, Rich Milburn <[EMAIL PROTECTED]> wrote:
>
> I got an answer about KMS. I hesitated about posting here but I think
> this just clears up the misconceptions expressed in the thread, it doesn't
> really disclose any new information…
>
> "There are 2 issues here, and a bit of a misunderstanding.
>
> "Windows Server codenamed "Longhorn" is still in beta. The KMS service
> for beta builds will not allow released products to activate. So, if you
> want to support both Longhorn and the released version of Vista with KMS,
> you will need 2 KMS hosts. However, when Longhorn is released, any KMS
> intended to activate Longhorn servers will also activate Vista volume
> clients.
>
> "Secondly, the KMS client will retrieve all SRV records from DNS. It
> will pick one at random and attempt to connect to it. If the client does not
> successfully activate or renew its activation, it will pick another KMS from
> the list, and so on until they succeed or they have tried the entire list.
> If a Vista KMS client contacts a beta KMS host, the client will receive an
> "invalid version" error and will proceed to try another KMS from the list
> provided by DNS.
>
> "I hope that helps clear things up."
>
> *-----------------------------------------------------------------------
> **
> **Rich Milburn**
> **MCSE, Microsoft MVP - Directory Services**
> Sr Network Analyst, Field Platform Development
> Applebee's International, Inc.**
> **4551 W. 107th St**
> **Overland Park, KS 66207**
> **913-967-2819 **
> **----------------------------------------------------------------------
> **
> **"I love the smell of red herrings in the morning" - anonymous*
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Rich Milburn
> *Sent:* Thursday, December 07, 2006 11:09 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] OT: Vista Activation and KMS
>
>
>
> > 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 put this up in the beta volume licensing group, hopefully there will
> be some MSFT response on this. I agree with you – the point of making it
> easy by allowing srv records is offset by the fact neither the VL client nor
> the KMS server can differentiate between Vista and LHS. Even if the
> solution is to update the KMS service prior to longhorn's release, and have
> separate srv records (one for Vista, one for longhorn, another for ??
> because you know they're on a roll now and will soon have other things doing
> VLA) personally I'd rather have multiple records than multiple KMS servers,
> and hard-coding reg keys or using MAKS for all servers is not really a good
> solution, IMHO.
>
>
>
> Rich
>
>
>
> *-----------------------------------------------------------------------
> **Rich Milburn
> **MCSE, Microsoft MVP - Directory Services
> Sr Network Analyst, Field Platform Development
> Applebee's International, Inc.**
> **4551 W. 107th St**
> **Overland Park, KS 66207 **
> **913-967-2819**
> **----------------------------------------------------------------------
> **
> **"I love the smell of red herrings in the morning" - anonymous *
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Harvey Kamangwitz
> *Sent: *Tuesday, December 05, 2006 11:41 PM
> *To:* ActiveDir@mail.activedir.org
> *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:* ActiveDir@mail.activedir.org
> *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] On Behalf Of
> > Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
> > Sent: Monday, December 04, 2006 1:12 PM
> > To: ActiveDir@mail.activedir.org
> > 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
> >
> > 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/activedir@mail.activedir.org/
> >
> > --
> > 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/activedir@mail.activedir.org/
>
>
>
>
> --
> 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
>
>
> *
> ------------------------------
> *
>
> *-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE-------** *
> *
> PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message
> or any attachments. This information is strictly confidential and may be
> subject to attorney-client privilege. This message is intended only for the
> use of the named addressee. If you are not the intended recipient of this
> message, unauthorized forwarding, printing, copying, distribution, or using
> such information is strictly prohibited and may be unlawful. If you have
> received this in error, you should kindly notify the sender by reply e-mail
> and immediately destroy this message. Unauthorized interception of this
> e-mail is a violation of federal criminal law. Applebee's International,
> Inc. reserves the right to monitor and review the content of all messages
> sent to and from this e-mail address. Messages sent to or from this e-mail
> address may be stored on the Applebee's International, Inc. e-mail system.
> *
> ------------------------------
>
> *
> ------------------------------
> -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE-------
> PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message
> or any attachments. This information is strictly confidential and may be
> subject to attorney-client privilege. This message is intended only for the
> use of the named addressee. If you are not the intended recipient of this
> message, unauthorized forwarding, printing, copying, distribution, or using
> such information is strictly prohibited and may be unlawful. If you have
> received this in error, you should kindly notify the sender by reply e-mail
> and immediately destroy this message. Unauthorized interception of this
> e-mail is a violation of federal criminal law. Applebee's International,
> Inc. reserves the right to monitor and review the content of all messages
> sent to and from this e-mail address. Messages sent to or from this e-mail
> address may be stored on the Applebee's International, Inc. e-mail system.
> *
>
> ------------------------------
>
>
