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:* [email protected]
*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:* [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] 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
>
> 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
*
------------------------------
*
*-------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.
*
------------------------------
