[Kevin G]

I have 150 HP workstations that shipped with WIndwos XP OEM. The customer
downgraded the license to Windwos 2000. They are now ready to deploy XP
company wide.

Q: Can I take an image of one of the machines using a program like Ghost,
with the OWM licenses and deploy it to all the other like machines? Is this
legal or do I need another type of license to do this?

Please advise,

Kevin

[Carey Frisch [MVP]]

Yes, but you'll have to enter each individual OEM Product Key
manually, then activate if prompted to do so.

--
Carey Frisch
Microsoft MVP
Windows XP - Shell/User
Microsoft Newsgroups

Get Windows XP Service Pack 2 with Advanced Security Technologies:
http://www.microsoft.com/athome/security/protect/windowsxp/choose.mspx

-------------------------------------------------------------------------------------------

"Kevin G" wrote:

| I have 150 HP workstations that shipped with WIndwos XP OEM. The customer
| downgraded the license to Windwos 2000. They are now ready to deploy XP
| company wide.
|
| Q: Can I take an image of one of the machines using a program like Ghost,
| with the OWM licenses and deploy it to all the other like machines? Is this
| legal or do I need another type of license to do this?
|
| Please advise,
|
| Kevin

[Kevin G]

How do I accomplish this without having to enter the key at each
workstation?

Kevin

"Carey Frisch [MVP]" <cnfrisch@nospamgmail.com> wrote in message
news:uiVWrF%23ZFHA.2940@tk2msftngp13.phx.gbl...
> Yes, but you'll have to enter each individual OEM Product Key
> manually, then activate if prompted to do so.
>
> --
> Carey Frisch
> Microsoft MVP
> Windows XP - Shell/User
> Microsoft Newsgroups
>
> Get Windows XP Service Pack 2 with Advanced Security Technologies:
> http://www.microsoft.com/athome/security/protect/windowsxp/choose.mspx
>
> -------------------------------------------------------------------------------------------
>
> "Kevin G" wrote:
>
> | I have 150 HP workstations that shipped with WIndwos XP OEM. The
> customer
> | downgraded the license to Windwos 2000. They are now ready to deploy XP
> | company wide.
> |
> | Q: Can I take an image of one of the machines using a program like
> Ghost,
> | with the OWM licenses and deploy it to all the other like machines? Is
> this
> | legal or do I need another type of license to do this?
> |
> | Please advise,
> |
> | Kevin
>

[Mike Brannigan [MSFT]]

"Kevin G" <Kevin@g.com> wrote in message
news:%23OpjCHDaFHA.2768@tk2msftngp13.phx.gbl...
> How do I accomplish this without having to enter the key at each
> workstation?
>

You can't, if you are reinstalling the original OEM Windows XP to each
machine. (unless they are BIOS locked (SLP) installs and do not need
activating over the Internet or via telephone)

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Kevin G" <Kevin@g.com> wrote in message
news:%23OpjCHDaFHA.2768@tk2msftngp13.phx.gbl...
> How do I accomplish this without having to enter the key at each
> workstation?
>
> Kevin
>
> "Carey Frisch [MVP]" <cnfrisch@nospamgmail.com> wrote in message
> news:uiVWrF%23ZFHA.2940@tk2msftngp13.phx.gbl...
>> Yes, but you'll have to enter each individual OEM Product Key
>> manually, then activate if prompted to do so.
>>
>> --
>> Carey Frisch
>> Microsoft MVP
>> Windows XP - Shell/User
>> Microsoft Newsgroups
>>
>> Get Windows XP Service Pack 2 with Advanced Security Technologies:
>> http://www.microsoft.com/athome/security/protect/windowsxp/choose.mspx
>>
>> -------------------------------------------------------------------------------------------
>>
>> "Kevin G" wrote:
>>
>> | I have 150 HP workstations that shipped with WIndwos XP OEM. The
>> customer
>> | downgraded the license to Windwos 2000. They are now ready to deploy
>> XP
>> | company wide.
>> |
>> | Q: Can I take an image of one of the machines using a program like
>> Ghost,
>> | with the OWM licenses and deploy it to all the other like machines? Is
>> this
>> | legal or do I need another type of license to do this?
>> |
>> | Please advise,
>> |
>> | Kevin
>>
>
>

[Daniel Sinclair]

Yeah, unfortunately, this is what the VLK versions are for. However, now you
have OEM, the easiest way you can resolve this is by having an image that
runs SysPrep against a floppy disk when it boots using a FullUnattended
setup.You'll need a different floppy disk for each workstation of course,
each with one of the 150 keys in it, but it will be easier than doing it all
fully manually.

1) Use SetupMgr to create an answer file, then add one of your 150
ProductKey= to 150 different files and put them on 150 different floppies.
2) Create your image using any one of the product keys, then add a command
to run SysPrep to teh RunOnce key in the registry. Shut down the machine and
take your ghost at that point.
3) put a floppy into each machine (each with a unique key) and multicast
blow the lot.

Note: You could also 'unattend' build each machine individually with 150
winnt.sif floppies.

You could also do something more sophistacated;

1) Write a simple web service that hands out one product key per IP address
2) Write a simple JScript task to fetch the product key when the image
boots, patch the SysPrep.inf file and sysprep the machines.

That's what I would do.

Daniel Sinclair
http://www.axxiant.com/

"Mike Brannigan [MSFT]" <mikebran@online.microsoft.com> wrote in message
news:um01wkDaFHA.1148@tk2msftngp13.phx.gbl...
> "Kevin G" <Kevin@g.com> wrote in message
> news:%23OpjCHDaFHA.2768@tk2msftngp13.phx.gbl...
>> How do I accomplish this without having to enter the key at each
>> workstation?
>>
>
> You can't, if you are reinstalling the original OEM Windows XP to each
> machine. (unless they are BIOS locked (SLP) installs and do not need
> activating over the Internet or via telephone)
>
> --
>
> Regards,
>
> Mike
> --
> Mike Brannigan [Microsoft]
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights
>
> Please note I cannot respond to e-mailed questions, please use these
> newsgroups
>
> "Kevin G" <Kevin@g.com> wrote in message
> news:%23OpjCHDaFHA.2768@tk2msftngp13.phx.gbl...
>> How do I accomplish this without having to enter the key at each
>> workstation?
>>
>> Kevin
>>
>> "Carey Frisch [MVP]" <cnfrisch@nospamgmail.com> wrote in message
>> news:uiVWrF%23ZFHA.2940@tk2msftngp13.phx.gbl...
>>> Yes, but you'll have to enter each individual OEM Product Key
>>> manually, then activate if prompted to do so.
>>>
>>> --
>>> Carey Frisch
>>> Microsoft MVP
>>> Windows XP - Shell/User
>>> Microsoft Newsgroups
>>>
>>> Get Windows XP Service Pack 2 with Advanced Security Technologies:
>>> http://www.microsoft.com/athome/security/protect/windowsxp/choose.mspx
>>>
>>> -------------------------------------------------------------------------------------------
>>>
>>> "Kevin G" wrote:
>>>
>>> | I have 150 HP workstations that shipped with WIndwos XP OEM. The
>>> customer
>>> | downgraded the license to Windwos 2000. They are now ready to deploy
>>> XP
>>> | company wide.
>>> |
>>> | Q: Can I take an image of one of the machines using a program like
>>> Ghost,
>>> | with the OWM licenses and deploy it to all the other like machines?
>>> Is this
>>> | legal or do I need another type of license to do this?
>>> |
>>> | Please advise,
>>> |
>>> | Kevin
>>>
>>
>>
>
>

[Jetro]

Well, unless you got a legal VL key this approach is not legal.
I believe there is a domain so forget about unattended setups and syspreps,
just clone the same activated OEM image (use RIS). During the time you can
change OEM product keys and local SIDs if you would need it (but why?).

[Jetro]

It was late :o)
IIRC, Windows activation should recalculate the hardware hash and ask
politely about the Product Key at the first boot of OEM/Retail clone.

[Daniel Sinclair]

> I believe there is a domain so forget about unattended setups and
> syspreps,
Huh? Why?

"Jetro" <somewhere@internet.space> wrote in message
news:ufQeWqLaFHA.1448@TK2MSFTNGP09.phx.gbl...
> Well, unless you got a legal VL key this approach is not legal.
> I believe there is a domain so forget about unattended setups and
> syspreps,
> just clone the same activated OEM image (use RIS). During the time you can
> change OEM product keys and local SIDs if you would need it (but why?).
>

[Jetro]

Because it's pointless.

[Daniel Sinclair]

Why is unattend and SysPrep pointless when you're in a domain?

"Jetro" <somewhere@internet.space> wrote in message
news:uPZn1ECbFHA.2420@TK2MSFTNGP15.phx.gbl...
> Because it's pointless.

[Jetro]

It's pointless cloning the OEM/Retail images unattended and sysprepped on
the same hardware in domain environment.

[Daniel Sinclair]

Why is it pointless?

"Jetro" <somewhere@internet.space> wrote in message
news:O$EmjMIbFHA.2416@TK2MSFTNGP09.phx.gbl...
> It's pointless cloning the OEM/Retail images unattended and sysprepped on
> the same hardware in domain environment.
>

[Jetro]

Because there is no point. It's possible to deploy 150 workstations faster
than to prepare 50 diskettes :o) If you know the point then show me.

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:ufQeWqLaFHA.1448@TK2MSFTNGP09.phx.gbl...
> Well, unless you got a legal VL key this approach is not legal.
> I believe there is a domain so forget about unattended setups and
> syspreps,
> just clone the same activated OEM image (use RIS). During the time you can
> change OEM product keys and local SIDs if you would need it (but why?).

Jetro

Even though you are joining a domain - it is important to correctly sysprep
the machine prior to joining the domain.
This ensures that the machines local SID is unique prior to it joining the
domain where it also acquires a domain based SID.
This has been a know problem for years (right back into the Windwos NT days)
and we have always advised against any form of "brutal" cloning where you
fail to correctly regenerate the SID for the local machine prior to joining
the domain. This is one fo the primary drivers for us releasing sysprep as
a tool.
Failure to follow this guidance can lead to an unsupported environment,
security issues and additional issues with future updates and upgrades.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:ufQeWqLaFHA.1448@TK2MSFTNGP09.phx.gbl...
> Well, unless you got a legal VL key this approach is not legal.
> I believe there is a domain so forget about unattended setups and
> syspreps,
> just clone the same activated OEM image (use RIS). During the time you can
> change OEM product keys and local SIDs if you would need it (but why?).
>

[Jetro]

Mike,

I know, I know these recommendations and explanations :o)

Workgroup environment and removable NTFS-based media is the only known
situations where duplicate local SIDs can cause the problems. We all know
the SysPrep was a Microsoft answer to mass NT rollouts on dissimilar
hardware, i.e. reality, and I greatly appreciate it (believe me) but its new
SID feature is not the main one in a domain environment.

I accept the reasons why MS or any other owner of any proprietary product
enforces a restricted support policy in various situations but it is far
from SID issues.

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:uNsnw0ObFHA.3132@TK2MSFTNGP09.phx.gbl...
> Mike,
>
> I know, I know these recommendations and explanations :o)
>
> Workgroup environment and removable NTFS-based media is the only known
> situations where duplicate local SIDs can cause the problems. We all know
> the SysPrep was a Microsoft answer to mass NT rollouts on dissimilar
> hardware, i.e. reality, and I greatly appreciate it (believe me) but its
> new
> SID feature is not the main one in a domain environment.
>
> I accept the reasons why MS or any other owner of any proprietary product
> enforces a restricted support policy in various situations but it is far
> from SID issues.
>

I am not at liberty to go into greater technical detail but it is sufficient
to say you should never ever be using machines (workstations or servers)
that have duplicate SIDs irrespective of their membership of a workgroup or
a domain in any circumstances.
Please do not advise posters that it is OK to do this.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:uNsnw0ObFHA.3132@TK2MSFTNGP09.phx.gbl...
> Mike,
>
> I know, I know these recommendations and explanations :o)
>
> Workgroup environment and removable NTFS-based media is the only known
> situations where duplicate local SIDs can cause the problems. We all know
> the SysPrep was a Microsoft answer to mass NT rollouts on dissimilar
> hardware, i.e. reality, and I greatly appreciate it (believe me) but its
> new
> SID feature is not the main one in a domain environment.
>
> I accept the reasons why MS or any other owner of any proprietary product
> enforces a restricted support policy in various situations but it is far
> from SID issues.
>

[Daniel Sinclair]

Either we're talking at cross purposes, or maybe I'm being dumb, but what is
it about "being in a domain" that makes it easier to "deploy 150
workstations" without SysPrep? How are you planning on deploying the
machines and making the SID changes?

"Jetro" <somewhere@internet.space> wrote in message
news:uAmLW0KbFHA.1148@tk2msftngp13.phx.gbl...
> Because there is no point. It's possible to deploy 150 workstations faster
> than to prepare 50 diskettes :o) If you know the point then show me.
>

[Daniel Sinclair]

This is nonesense. Its crucial that the machine SID is different, especially
in a domain, and as Mike implies, there are other things that change, or may
need to be changed in the future which mandate the use of SysPrep in all
cases. Nobody says you need to use a floppy disk of course.

The SID is used for amongst other things;
* Generating an auto-configured IP address (OK, this isn't so desperate if
you've a DHCP server)
* Establishing a secure trust relationship with the domain, this is pretty
crucial since you need this to authenticate safely and for identification.
* COM+
etc

As a matter of fact I'm surprised you can join a domain with cloned images
using the same machine SID.

"Jetro" <somewhere@internet.space> wrote in message
news:uNsnw0ObFHA.3132@TK2MSFTNGP09.phx.gbl...
> Mike,
>
> I know, I know these recommendations and explanations :o)
>
> Workgroup environment and removable NTFS-based media is the only known
> situations where duplicate local SIDs can cause the problems. We all know
> the SysPrep was a Microsoft answer to mass NT rollouts on dissimilar
> hardware, i.e. reality, and I greatly appreciate it (believe me) but its
> new
> SID feature is not the main one in a domain environment.
>
> I accept the reasons why MS or any other owner of any proprietary product
> enforces a restricted support policy in various situations but it is far
> from SID issues.
>

[Mike Brannigan [MSFT]]

"Daniel Sinclair" <danieljsinclair@community.nospam> wrote in message
news:%23ch6KkPbFHA.1360@TK2MSFTNGP10.phx.gbl...
> Either we're talking at cross purposes, or maybe I'm being dumb, but what
> is it about "being in a domain" that makes it easier to "deploy 150
> workstations" without SysPrep? How are you planning on deploying the
> machines and making the SID changes?

That's the point - he erroneous assumes that as a machine joining a domain
gets a new Domain SID that the local SID is not relevant; so he thinks he
can just brutal clone the machines, ignore the SYSPREP and SID regeneration
and join the domain thus saving some time.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Daniel Sinclair" <danieljsinclair@community.nospam> wrote in message
news:%23ch6KkPbFHA.1360@TK2MSFTNGP10.phx.gbl...
> Either we're talking at cross purposes, or maybe I'm being dumb, but what
> is it about "being in a domain" that makes it easier to "deploy 150
> workstations" without SysPrep? How are you planning on deploying the
> machines and making the SID changes?
>
> "Jetro" <somewhere@internet.space> wrote in message
> news:uAmLW0KbFHA.1148@tk2msftngp13.phx.gbl...
>> Because there is no point. It's possible to deploy 150 workstations
>> faster
>> than to prepare 50 diskettes :o) If you know the point then show me.
>>
>
>

[Daniel Sinclair]

Ah I see. I was probably for the good of the list then that I didn't leave
the "its pointless" statement unchallenged :)

"Mike Brannigan [MSFT]" <mikebran@online.microsoft.com> wrote in message
news:%23fktt2PbFHA.4004@TK2MSFTNGP10.phx.gbl...
> "Daniel Sinclair" <danieljsinclair@community.nospam> wrote in message
> news:%23ch6KkPbFHA.1360@TK2MSFTNGP10.phx.gbl...
>> Either we're talking at cross purposes, or maybe I'm being dumb, but what
>> is it about "being in a domain" that makes it easier to "deploy 150
>> workstations" without SysPrep? How are you planning on deploying the
>> machines and making the SID changes?
>
> That's the point - he erroneous assumes that as a machine joining a domain
> gets a new Domain SID that the local SID is not relevant; so he thinks he
> can just brutal clone the machines, ignore the SYSPREP and SID
> regeneration and join the domain thus saving some time.
>
> --
>
> Regards,
>
> Mike
> --
> Mike Brannigan [Microsoft]
>

[Jetro]

Domain accounts don't have duplicate SIDs. Period.

I never ill-advised anyone. If someone is so dumb or desperate to get advice
without further research or understanding the details this is not my
problem.

Just curious why you're not at liberty to go into details but take a risk to
advise and oppose. I don't think a bracketed abbreviation can be enough.

[Jetro]

No wonder you are surprised. Real life and fairytales differ sometimes and
any theory without experience is dead. Try again to find an example when
local SID is involved in domain environment.

[Jetro]

I don't assume or think but rather know. Any sound objection against "brutal
clone"?

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:utWmyAXbFHA.2796@TK2MSFTNGP10.phx.gbl...
> Domain accounts don't have duplicate SIDs. Period.
>

I never said they did.

> I never ill-advised anyone. If someone is so dumb or desperate to get
> advice
> without further research or understanding the details this is not my
> problem.
>

You have advised the posters on this thread that it is OK to allow machines
with duplicate SIDs to join and participate in domains. - This is not
correct - you should never use any machine in any environment with a
duplicate SID period.

> Just curious why you're not at liberty to go into details but take a risk
> to
> advise and oppose. I don't think a bracketed abbreviation can be enough.
>

I am not at liberty to discuss specific technical or implementation details
of our products in a public forum. It is enough to say that you should not
use machine with duplicate SIDs.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:utWmyAXbFHA.2796@TK2MSFTNGP10.phx.gbl...
> Domain accounts don't have duplicate SIDs. Period.
>
> I never ill-advised anyone. If someone is so dumb or desperate to get
> advice
> without further research or understanding the details this is not my
> problem.
>
> Just curious why you're not at liberty to go into details but take a risk
> to
> advise and oppose. I don't think a bracketed abbreviation can be enough.
>

[Daniel Sinclair]

Well I am surprised, yes. But as for why you probably shouldn't do this,
didn't I just give three? Or can you illustrate that there isn't a security
risk in SID sharing.

I also feel that its somewhat irresponsible to promote this activity on the
list against Microsoft best practice because even it you can get it to work
now you can't say for sure that this won't suddenly fail one day when a
service pack is applied and bring a domain to its knees. You'd then be on
shaky ground with respect to support.

"Jetro" <somewhere@internet.space> wrote in message
news:uuoriGXbFHA.2936@tk2msftngp13.phx.gbl...
> No wonder you are surprised. Real life and fairytales differ sometimes and
> any theory without experience is dead. Try again to find an example when
> local SID is involved in domain environment.
>

[Jetro]

Daniel,

You can't oppose. Take two clones, crossover cable, create APIPA network,
and you'd be surprised again.

With regard to sudden fails, it could happen with anyone at any time for any
reason. It could happen with you, me, BG, the whole Microsoft, the Internet
etc. OTOH, it could never happen.

I believe the last thing Microsoft would want is that kinda check the local
SIDs in a network and disable or restrict a functionality if duplicates were
found. Bug-2000 (a big lie also, BTW) will be a parody of those
consequences.

[Jetro]

Mike,

Please read inlines.

>> Domain accounts don't have duplicate SIDs. Period.

> I never said they did.

I never said anything else.

>> I never ill-advised anyone. If someone is so dumb or desperate to get
>> advice
> > without further research or understanding the details this is not my
> > problem.

> You have advised the posters on this thread that it is OK to allow
> machines
> with duplicate SIDs to join and participate in domains. - This is not
> correct - you should never use any machine in any environment with a
> duplicate SID period.

See my first comment. Actually I said "During the time you can change...
local SIDs" so you misinterpret.

>> Just curious why you're not at liberty to go into details but take a risk
>> to
>> advise and oppose. I don't think a bracketed abbreviation can be enough.

> I am not at liberty to discuss specific technical or implementation
> details
> of our products in a public forum. It is enough to say that you should not
> use machine with duplicate SIDs.

See my first comment.

Unfortunately this is not "enough to say" in a public technical forum
without any proof such as technical documentation. "Enough to say" argument
is the last one when you argue with your dumb kids only and you really have
no other arguments.

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:eA87cEcbFHA.2520@TK2MSFTNGP09.phx.gbl...
>
> Unfortunately this is not "enough to say" in a public technical forum
> without any proof such as technical documentation. "Enough to say"
> argument
> is the last one when you argue with your dumb kids only and you really
> have
> no other arguments.
>

Jetro,

When it comes to the internal operation of Windows (which is not subject to
public disclosure) and our intellectual property - it is entirely sufficient
for me to tell that you should not ever use machines with duplicate SIDs in
a public forum.


To use your analogy of kids arguing - lets just take that a step further to
parent to child.
It is enough to say to children who either would not understand or who
should not be exposed to the details of something that this is the fact and
you as the parent are not required to provide any further evidence.
This is to in no way downplay you technical capabilities but when it comes
to issues related to the internals of our products sometime we have to just
make a statement of fact and leave it at that.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:eA87cEcbFHA.2520@TK2MSFTNGP09.phx.gbl...
> Mike,
>
> Please read inlines.
>
>>> Domain accounts don't have duplicate SIDs. Period.
>
>> I never said they did.
>
> I never said anything else.
>
>>> I never ill-advised anyone. If someone is so dumb or desperate to get
>>> advice
>> > without further research or understanding the details this is not my
>> > problem.
>
>> You have advised the posters on this thread that it is OK to allow
>> machines
>> with duplicate SIDs to join and participate in domains. - This is not
>> correct - you should never use any machine in any environment with a
>> duplicate SID period.
>
> See my first comment. Actually I said "During the time you can change...
> local SIDs" so you misinterpret.
>
>>> Just curious why you're not at liberty to go into details but take a
>>> risk
>>> to
>>> advise and oppose. I don't think a bracketed abbreviation can be enough.
>
>> I am not at liberty to discuss specific technical or implementation
>> details
>> of our products in a public forum. It is enough to say that you should
>> not
>> use machine with duplicate SIDs.
>
> See my first comment.
>
> Unfortunately this is not "enough to say" in a public technical forum
> without any proof such as technical documentation. "Enough to say"
> argument
> is the last one when you argue with your dumb kids only and you really
> have
> no other arguments.
>

[Jetro]

Mike,

So there is no documented evidence?

Microsoft does not provide support for computers that have been installed by
duplicating fully installed copies of Windows - this is her unconditional
right, as I've said, but who cares? If someone can determine that the core
of her problems is a duplicate SID then this someone doesn't need Microsoft
support :o)

Here is a theoretical cause when duplicate SIDs can be allocated in domain
environment.

Each DC maintains a pool of relative IDs that is used to create SIDs. When
80% of the relative ID pool is consumed, the DC requests a new pool of
relative identifiers from the RID operations master. This ensures that the
same pool of relative IDs is never allocated to different DCs, and prevents
the allocation of duplicate SIDs. However, because it is possible (but rare)
for a duplicate relative ID pool to be allocated, you need to identify those
accounts that have been issued duplicate SIDs to prevent incorrect security
from being applied.

Duplicate relative ID pools can occur if the administrator seizes the RID
master role while the original relative ID master is operational but
temporarily disconnected from the network. In typical practice, after one
replication cycle, the RID master role is assumed by just one DC. However,
before the role ownership is resolved, two different DCs might each request
a new relative ID pool and be allocated the same relative ID pool.

This is the only particular situation when an Admin should use the
ntdsutil.exe tool, check, and cleanup duplicate SIDs if exist.

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:%23d7GsGdbFHA.2796@TK2MSFTNGP10.phx.gbl...
> Mike,
>
> So there is no documented evidence?
>

Our statement of not using any machine with a duplicate SID is sufficient.

> Microsoft does not provide support for computers that have been installed
> by
> duplicating fully installed copies of Windows - this is her unconditional
> right, as I've said, but who cares? If someone can determine that the core
> of her problems is a duplicate SID then this someone doesn't need
> Microsoft
> support :o)
>

I fail to see your point - we make a simple direct statement and you still
wish to argue the merits of it.
If you wish to ignore our stated recommendations the that as you say is your
right to do so - but you are making potential problems for you and your
customers now and in the future.

> Here is a theoretical cause when duplicate SIDs can be allocated in domain
> environment.
>
<snipped as not relevant>

It is not about Domain SID duplication - the simple fact as I have stated
over and over again - you should never under any circumstances use machine
that have been incorrectly built that has resulted in duplicate local
machine SIDs between those machines.


--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:%23d7GsGdbFHA.2796@TK2MSFTNGP10.phx.gbl...
> Mike,
>
> So there is no documented evidence?
>
> Microsoft does not provide support for computers that have been installed
> by
> duplicating fully installed copies of Windows - this is her unconditional
> right, as I've said, but who cares? If someone can determine that the core
> of her problems is a duplicate SID then this someone doesn't need
> Microsoft
> support :o)
>
> Here is a theoretical cause when duplicate SIDs can be allocated in domain
> environment.
>
> Each DC maintains a pool of relative IDs that is used to create SIDs. When
> 80% of the relative ID pool is consumed, the DC requests a new pool of
> relative identifiers from the RID operations master. This ensures that the
> same pool of relative IDs is never allocated to different DCs, and
> prevents
> the allocation of duplicate SIDs. However, because it is possible (but
> rare)
> for a duplicate relative ID pool to be allocated, you need to identify
> those
> accounts that have been issued duplicate SIDs to prevent incorrect
> security
> from being applied.
>
> Duplicate relative ID pools can occur if the administrator seizes the RID
> master role while the original relative ID master is operational but
> temporarily disconnected from the network. In typical practice, after one
> replication cycle, the RID master role is assumed by just one DC. However,
> before the role ownership is resolved, two different DCs might each
> request
> a new relative ID pool and be allocated the same relative ID pool.
>
> This is the only particular situation when an Admin should use the
> ntdsutil.exe tool, check, and cleanup duplicate SIDs if exist.
>

[Daniel Sinclair]

Jetro
You obviously have some good first hand knowledge of the successes of SID
sharing within a domain, hence your overly flippant first comment on this
thread. It is however the kind of statement that needs qualifing and I still
don't believe its something that should be promoted to perhaps novices
reading this list, especially when its strictly against the advice of the
manufacturer.

With regards to future failures I don't think its a matter of introducing
enforced constraints for no reason. Microsoft would be unlikely deliberately
dissalow duplicate SIDs for the sake of it. However, you probably already
know of the security issues with machines sharing duplicate SIDs, we know
they're also used to generate autoconfigured IP addresses (undocumented) and
I believe in other areas (eg. COM+) in configurations which you may not have
encountered on your site, so there may very well be others, now or in the
future. Its all down to the internal implementation of windows. What you
'observe' on Windows 2003 SP1 now may very well not be the same in SP2 or
Longhorn.

I think the bottom line is this: Since the manufacturer advises that you
don't duplicate SIDs they may have good reason, and possibly reasons that
they aren't at liberty to disclose which may involve future plans for using
the machine SID. This may be a new feature they decide to introduce in some
future version which would not work for all those users who had chosen to
implement their infrastructure against the manufacturers advice.

I fail to see how you can possibly argue with this point.

If you ill adivse users to take this route, are you suggesting that you
personally will be in a position to support them where Microsoft may not?
Are you offering to take liablity for the consequences? If not then you
shouldn't be promoting it blindly...period!

By all means do use your extensive knowledge of how domain SIDs are used,
and by all means share your valuable experience and stories of what you've
succeeded to do that is against either common knowledge or best practice, in
fact I and others on this list would welcome it since its something that MS
employees may not be at liberty to discuss for various reasons. But do
qualify your statements and don't make flippant, throwaway, unqualified
comments on this list that could be interpreted as directly by readers who
may take your advice without understanding the consequences and may find
themselves in an unwanted future position.

[Jetro]

There is your own statement in this thread only. If you can change an
appropriate MS KB article or EULA then do it and I stop my practice.
Everything else is irrelevant.

[Jetro]

Daniel,

Haven't I said in initial post "you can change... the local SIDs if you
would need it"? <shrug> Please do not misinterpret.

The manufacturer never advises that you don't duplicate SIDs. MS
*recommends* that you use a supported method to avoid compromising security.
How? An identical computer SID compromises security in Workgroup
environments, and removable media security can also be compromised in
networks with multiple identical computer SIDs.

MS states that it "does not provide support..." and I completely understand
and support that position. OTOH the policy as such can be quite inadequate.
For instance, you purchase a computer with XPHome preinstalled, wipe it off,
and install something else. On 365th day afternoon the box starts hanging up
and freezing. You check the components and find out the motherboard must be
replaced. You call the service and they tell you to use a QuickRestore CD
before you can get any invaluable help. Now you get stumbled - you got 20-30
GB of G-d-only-knows-what-applications and you got neither spare disk nor
up-to-date volume image in the middle of nowhere. Sadly, does anyone need
such support if the motherboard will be inevitably replaced? But this is a
manufacturer's support policy too.

I'm still insisting that no-one should takes any suggestions without further
investigation or *a priori* unless you trust the source or get an order;
it's just a brain reload, a light at the end of the tunnel, unblocking...
You got your systems screwed up and this is your responsibility to fix it or
kill it, so bear it.

Good luck.

[Mike Brannigan [MSFT]]

Jetro,

I'm sorry but if you are not willing to expect the statement directly from a
subject matter expert on Windows and Active Directory then I'm not sure what
else we can do to help you.
Our statements are clear both here and in our own KB articles -
for example
http://support.microsoft.com/default.aspx?scid=kb;en-us;162001
and
http://support.microsoft.com/default.aspx?scid=kb;en-us;314828

Ignore this at your own risk (and at your clients too if you actually do
client facing work) but we have made our position plain and clear to you.


--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:OfxSbBhbFHA.3492@TK2MSFTNGP14.phx.gbl...
> There is your own statement in this thread only. If you can change an
> appropriate MS KB article or EULA then do it and I stop my practice.
> Everything else is irrelevant.
>

[Mike Brannigan [MSFT]]

"Jetro" <somewhere@internet.space> wrote in message
news:uXTz$ThbFHA.1608@TK2MSFTNGP10.phx.gbl...
> Daniel,
>
> Haven't I said in initial post "you can change... the local SIDs if you
> would need it"? <shrug> Please do not misinterpret.
>
> The manufacturer never advises that you don't duplicate SIDs.

Yes we do - please see my other post. And I have also clearly stated this.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

"Jetro" <somewhere@internet.space> wrote in message
news:uXTz$ThbFHA.1608@TK2MSFTNGP10.phx.gbl...
> Daniel,
>
> Haven't I said in initial post "you can change... the local SIDs if you
> would need it"? <shrug> Please do not misinterpret.
>
> The manufacturer never advises that you don't duplicate SIDs. MS
> *recommends* that you use a supported method to avoid compromising
> security.
> How? An identical computer SID compromises security in Workgroup
> environments, and removable media security can also be compromised in
> networks with multiple identical computer SIDs.
>
> MS states that it "does not provide support..." and I completely
> understand
> and support that position. OTOH the policy as such can be quite
> inadequate.
> For instance, you purchase a computer with XPHome preinstalled, wipe it
> off,
> and install something else. On 365th day afternoon the box starts hanging
> up
> and freezing. You check the components and find out the motherboard must
> be
> replaced. You call the service and they tell you to use a QuickRestore CD
> before you can get any invaluable help. Now you get stumbled - you got
> 20-30
> GB of G-d-only-knows-what-applications and you got neither spare disk nor
> up-to-date volume image in the middle of nowhere. Sadly, does anyone need
> such support if the motherboard will be inevitably replaced? But this is a
> manufacturer's support policy too.
>
> I'm still insisting that no-one should takes any suggestions without
> further
> investigation or *a priori* unless you trust the source or get an order;
> it's just a brain reload, a light at the end of the tunnel, unblocking...
> You got your systems screwed up and this is your responsibility to fix it
> or
> kill it, so bear it.
>
> Good luck.
>

[Jetro]

Mike,

You intentionally misquote and misinterpret me again. See my other post.

[Jetro]

Mike,

Don't you think I never read these two and other articles. Change them and
clearly state that "A domain should never under any circumstances comprise
of the machines with duplicate local SID" and why, if you can. Again, I
accept that "MS doesn't provide support..." etc but you deliberately
misinterpret the articles or just don't understand the matter. Do they teach
you to lie in [MSFT]? Did your mother teach you to lie?

P.S. As I supposed, a "subject matter expert on Windows and Active
Directory" is your only "irrefutable argument". Wadda ya expect - that I
shoot or drown myself? To me it's another wording of "I'm not at liberty to
say but nevertheless talk". Thanks G-d, you don't argue in terms of MS
certification yet. Believe me, I've seen enough of self-proclaimed Windows
"genii" who didn't know the computing basics. Don't fall into the same trap
and never say publicly "I am an expert".