date:20060817

Not quite.  You need to escape the comma like so:

(&(objectCategory=person)(objectClass=user)(displayName=phelps\, k*))

--Paul

- Original Message - 
From: "Matheesha Weerasinghe" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 14, 2006 8:46 PM
Subject: Re: [ActiveDir] LDAP Logon Name

All I did was fix your query. It seemed like you were trying to do a
search for users who have "phelps,k" as the start of their
displayname.

I assume the printer wants a DN to do lookups. Any AD user should be
able to bind. But I dont know what it does with the bind credentials.
I've never configured a printer that needed to be given credentials to
an LDAP directory. Does it look at who submitted the job and do a
query for the persons email address and send them an email that its
done? I dont know.

You need to tell us how the LDAP credentials are going to be used by
the printer. Otherwise it may appear that we are not helpful. Which, I
well may be not ;-)

Sorry

M@

On 8/14/06, Alex Alborzfard <[EMAIL PROTECTED]> wrote:

Logon ID? Most likely the DN, but I need an account that can do the bind.

Per HP documentation after running the search, I am supposed to find the 
search prefix, which should begin after the individual user's CN.

This is the example right from documentation:

>> Dn: 
>> [EMAIL PROTECTED],OU=US,OU=Users,OU=Account,DC=americas,DC=cpqcorp,DC=net

I tried M@'s query, it worked…well kind of…it didn't generate an error, 
but got 0 entries on Matched DNs L

I also tried your tree view suggestion, but that didn't give me anything 
I could use for this printer.

I don't see anything even close to it. I'm beginning to HATE LDAP and HP 
both!!!

Alex

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick

Sent: Monday, August 14, 2006 1:53 PM

To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Logon Name

To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Logon Name

Agreed. But does your printer search for the logon ID? I doubt it.  Most 
LDAP authentication (I HATE that term) will use the DN of the user: 
cn=user,cn=users,dc=domain,dc=com would be default.

From there it should be able to lookup the mail address in the directory.

You should specify the service account it will use to bind to the 
directory and the password and it should be fine from there.  To see that 
information, use ldp, and rather than search, use the tree view and 
navigate to it. (note: when the tree asks you for a dn value, leave it 
blank and press OK.)

Al

On 8/14/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> wrote:

Your ldap filter doesnt look correct.

M@

On 8/14/06, Alex Alborzfard <[EMAIL PROTECTED] > wrote:

According to product documentation, I have to configure embedded ldap
authentication. Apparently this printer has an Embedded Web Server
(EWS).
However, when I follow the documentation, using ldp tool, it fails when
trying to query ldap. The message I get is this:

***Searching...
ldap_search_s(ld, "DC=pharmanet,DC=com", 2,
"(&(objectclass=person)displayname=phelps,k*))", NULL,  0, &msg)
Error: Search: Filter Error. <87>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:

I connect to ldp as member of Domain Admins and Schema Admins, with the
same result.

Any ideas?

Alex

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko
Sent: Wednesday, August 09, 2006 3:05 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Logon Name

Alex Alborzfard wrote:
> We have a HP printer/scanner that we want to setup for emailing
scanned
> documents.
>
> Management wants to ensure only domain users with email addresses can
do
> this.
>
> There is an option for setting up LDAP gateway, where you can set user

> name & password up.
>
> It's asking for LDAP logonname. I have tried my user name and account
> anme, but it didn't work.
>
> I looked it up in ADSIedit, but I couldn't find it.

I think that simplest way would be to refer to product documentation but

I would try to use DN, or CN (in CN=... format) of this user.

--
Tomasz Onyszko
http://www.w2k.pl/blog/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

.+-wm ibb+ڲKE0+v*?.+-jq.+-j!irدyثi

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Re: [ActiveDir] LDAP Logon Name




You need to escape the comma, as a comma 
is a delimiter and in the case of displayName it shouldn't be a 
delimiter:
 
(&(objectCategory=person)(objectClass=user)(displayName=phelps\, 
k*))
 
 
I've not read the whole thread, so can't 
discuss whether or not this is the best way to do what you want.  I will 
say I feel for you re. the HP documentation.  I had some fun getting the AD 
iLO integration stuff to work because the guide wasn't very helpful at 
explaining what format and syntax things wanted.  I found the help on the 
administration pages better, and simply tried a number of things that I thought 
should work.
 
 
--Paul

  - Original Message - 
  From: 
  Alex Alborzfard 
  To: ActiveDir@mail.activedir.org 
  
  Sent: Monday, August 14, 2006 8:22 
  PM
  Subject: RE: [ActiveDir] LDAP Logon 
  Name
  
  
  Good catch, but the 
  corrected query still didnt work! L
   
  
  Alex
  
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Andrew CaceSent: Monday, August 14, 2006 2:50 
  PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] LDAP Logon 
  Name
   
  In the error below, 
  the LDAP filter is 
  "(&(objectclass=person)displayname=phelps,k*))".  You 
  missed the opening parenthesis before displayname.
   
  -Andrew
   
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Alex AlborzfardSent: Monday, August 14, 2006 1:24 
  PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] LDAP Logon 
  Name
   
  That was exactly the 
  same as HP documentation. Ill try your filter and will post the 
  result.
   
  Thanks
   
  
  Alex
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Matheesha 
  WeerasingheSent: Monday, 
  August 14, 2006 1:43 PMTo: 
  ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] LDAP Logon 
  Name
   
  
  I assume you need a filter such as 
  "(&(objectcategory=person)(objectclass=user)(displayname=phelps,k*))" 
  
  
   
  
  I optimised the user object search and put a opening 
  bracket when specifying the displayname.
  
   
  
  M@ 
  
  On 8/14/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> 
  wrote: 
  
  
  Your ldap filter doesnt look 
  correct.
  
  
   
  
  M@ 
  
  
  On 8/14/06, Alex 
  Alborzfard <[EMAIL PROTECTED] > wrote: 
  
  According to product documentation, I have to 
  configure embedded ldapauthentication. Apparently this printer has an 
  Embedded Web Server (EWS).However, when I follow the documentation, 
  using ldp tool, it fails whentrying to query ldap. The message I get is 
  this:***Searching...ldap_search_s(ld, "DC=pharmanet,DC=com", 
  2,"(&(objectclass=person)displayname=phelps,k*))", NULL,  0, 
  &msg)Error: Search: Filter Error. <87>Server 
  error:Error<94>: ldap_parse_result failed: No result present in 
  messageGetting 0 entries:I connect to ldp as member of Domain 
  Admins and Schema Admins, with thesame result.Any 
  ideas?Alex-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Tomasz 
  Onyszko Sent: Wednesday, August 09, 2006 3:05 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] 
  LDAP Logon Name Alex 
  Alborzfard wrote:> We have a HP printer/scanner that 
  we want to setup for emailing scanned> documents.>> 
  Management wants to ensure only domain users with email addresses 
  cando> this.>> There is an option for setting up LDAP 
  gateway, where you can set user > name & password 
  up.>> It's asking for LDAP logonname. I have tried my user name 
  and account > anme, but it didn't work.>> I looked it up 
  in ADSIedit, but I couldn't find it. I think that simplest way would 
  be to refer to product documentation butI would try to use DN, or CN 
  (in CN=... format) of this user. --Tomasz Onyszkohttp://www.w2k.pl/blog/ - 
  (PL)http://blogs.dirteam.com/blogs/tomek/ - (EN)List 
  info   : http://www.activedir.org/List.aspxList 
  FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList 
  info   : http://www.activedir.org/List.aspxList 
  FAQ: http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx

Re: [ActiveDir] LDAP Logon Name

2006-08-17 Thread Matheesha Weerasinghe

Thanks Paul

M@

On 8/17/06, Paul Williams <[EMAIL PROTECTED]> wrote:

You need to escape the comma, as a comma is a delimiter and in the case of
displayName it shouldn't be a delimiter:

(&(objectCategory=person)(objectClass=user)(displayName=phelps\,
k*))

I've not read the whole thread, so can't discuss whether or not this is the
best way to do what you want.  I will say I feel for you re. the HP
documentation.  I had some fun getting the AD iLO integration stuff to work
because the guide wasn't very helpful at explaining what format and syntax
things wanted.  I found the help on the administration pages better, and
simply tried a number of things that I thought should work.

--Paul

- Original Message -
From: Alex Alborzfard
To: ActiveDir@mail.activedir.org
Sent: Monday, August 14, 2006 8:22 PM
Subject: RE: [ActiveDir] LDAP Logon Name

Good catch, but the corrected query still didn't work! L

Alex

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Cace
Sent: Monday, August 14, 2006 2:50 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] LDAP Logon Name

In the error below, the LDAP filter is
"(&(objectclass=person)displayname=phelps,k*))".  You
missed the opening parenthesis before displayname.

-Andrew

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Alex Alborzfard
Sent: Monday, August 14, 2006 1:24 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] LDAP Logon Name

That was exactly the same as HP documentation. I'll try your filter and will
post the result.

Thanks

Alex

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matheesha Weerasinghe
Sent: Monday, August 14, 2006 1:43 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Logon Name

I assume you need a filter such as
"(&(objectcategory=person)(objectclass=user)(displayname=phelps,k*))"

I optimised the user object search and put a opening bracket when specifying
the displayname.

M@

On 8/14/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> wrote:

Your ldap filter doesnt look correct.

M@

On 8/14/06, Alex Alborzfard <[EMAIL PROTECTED] > wrote:

According to product documentation, I have to configure embedded ldap
authentication. Apparently this printer has an Embedded Web Server
(EWS).
However, when I follow the documentation, using ldp tool, it fails when
trying to query ldap. The message I get is this:

***Searching...
ldap_search_s(ld, "DC=pharmanet,DC=com", 2,
"(&(objectclass=person)displayname=phelps,k*))", NULL,  0,
&msg)
Error: Search: Filter Error. <87>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:

I connect to ldp as member of Domain Admins and Schema Admins, with the
same result.

Any ideas?

Alex

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tomasz Onyszko
Sent: Wednesday, August 09, 2006 3:05 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Logon Name

Alex Alborzfard wrote:
> We have a HP printer/scanner that we want to setup for emailing
scanned
> documents.
>
> Management wants to ensure only domain users with email addresses can
do
> this.
>
> There is an option for setting up LDAP gateway, where you can set user

> name & password up.
>
> It's asking for LDAP logonname. I have tried my user name and account
> anme, but it didn't work.
>
> I looked it up in ADSIedit, but I couldn't find it.

I think that simplest way would be to refer to product documentation but

I would try to use DN, or CN (in CN=... format) of this user.

--
Tomasz Onyszko
http://www.w2k.pl/blog/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

RE: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust Builders

2006-08-17 Thread Han Valk

First forgive my ignorance, I didn't that the group should only exist in the
forest root domain. But how is it possible that CHILDDOMAIN\Incoming Forest
Trust Builders has permissions on the child domain in ADUC when there
shouldn't be a CHILDDOMAIN\Incoming Forest Trust Builders?

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Matheesha Weerasinghe
> Sent: Monday, August 14, 2006 19:37
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest 
> Trust Builders
> 
> Its only in the forest domain IIRC ;-)
>  
> M@
> 
>  
> On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote: 
> 
>   No??? Child domain.
>   
>   > -Original Message-
>   > From: [EMAIL PROTECTED] 
>  
>   > [mailto:[EMAIL PROTECTED] On Behalf Of
>   > Matheesha Weerasinghe
>   > Sent: Monday, August 14, 2006 17:38 
>   > To: ActiveDir@mail.activedir.org
>   > Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest
>   > Trust Builders
>   >
>   > By the way you are looking for this on the forest root right? 
>   >
>   > M@
>   >
>   >
>   > On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote:
>   >
>   >   Yep logged in as Domain Admin.
>   >
>   >   > -Original Message- 
>   >   > From: [EMAIL PROTECTED]
>   > 
>   >   > [mailto:[EMAIL PROTECTED] 
> On Behalf Of
>   >   > Matheesha Weerasinghe
>   >   > Sent: Monday, August 14, 2006 13:00 
>   >   > To: ActiveDir@mail.activedir.org
>   >   > Subject: Re: [ActiveDir] Recreate 
> BUILTIN\Incoming Forest
>   >   > Trust Builders
>   >   > 
>   >   > I am wondering if there are ACLs defined on 
> the group itself
>   >   > or the OU above to prevent you from seen it. 
> Do you see it as
>   >   > the Administrator account of the domain? 
>   >   >
>   >   > M@
>   >   >
>   >   >
>   >   > On 8/14/06, Han Valk < [EMAIL PROTECTED]
>   >   > > wrote:
>   >   >
>   >   >   Problem is I don't see it anymore in the BUILTIN
>   >   > container. Strange thing is
>   >   >   that if I look at the security of the 
> domain object in 
>   >   > ADUC Incoming Forest
>   >   >   Trust Builders is there.
>   >   >
>   >   >   > -Original Message-
>   >   >   > From: 
> [EMAIL PROTECTED] 
>  
>   >   >   > [mailto: [EMAIL PROTECTED]
>   >   >   > ] On Behalf Of
>   >   >   > Matheesha Weerasinghe
>   >   >   > Sent: Monday, August 14, 2006 10:22
>   >   >   > To: ActiveDir@mail.activedir.org 
>  
>   >   >   > Subject: Re: [ActiveDir] Recreate
>   > BUILTIN\Incoming Forest
>   >   >   > Trust Builders
>   >   >   >
>   >   >   > I dont think so. objectsid attribute 
> is a systemonly 
>   >   >   > attribute. Personally I am impressed 
> of that "smart
>   >   >   > co-worker" that managed to delete it.
>   > According to the AD
>   >   >   > Delegation appendices 
>   >   >   >
>   >   > 
> http://www.microsoft.com/downloads/details.aspx?FamilyID=29dba
>   >   >   
> e88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en > 
>   >   >
>   >    >   >   
> ae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en>  its 
>   >   > not > possible to move
>   >   >   delete rename this group.
>   >   >   >
>   >   >   > May be he exploited the dynamic objects
>   > feature in Windows 
>   >   >   > 2003 RTM?
>   >   >   >
>   >   >
>   > 
> http://blogs.dirteam.com/blogs/tomek/archive/2006/06/23/1175.aspx 
>   >   >   >
>   >   >   >
>   >   >   > M@
>   >   >   >
>   >   >   >
>   >   >   >
>   >   >   > On 8/14/06, Han Valk < 
> [EMAIL PROTECTED]> wrote:
>   >   >   >
>   >   >   >   Hi,
>   >   >   >
>   >   >   >   A smart co-worker deleted the 
>   > BUILTIN\Incoming Forest
>   >   >   > Trust Builders group.
>   >   >   >   Is it possible to recreate this group
>   > with the same
>   >   >   > well known SID? 
>   >   >   >   Authoritative restore is out of 
> the question,
>   >   >   > deletetion is too long ago.
>   >   >   >
>   >   >   >   Han Valk.
>

Re: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust Builders

I'm not in a position to test whether this is a forest-wide or domain-wide 
principal.


However, when you can't find something you think should be there, you should 
search the GC.  I've seen numerous people have issues with a user or group 
"not existing" only to find it's in a parent domain.


Use ADFIND or LDP to search the GC.

Also, what are the actual permissions you are seeing and where?


--Paul

- Original Message - 
From: "Han Valk" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 17, 2006 10:24 AM
Subject: RE: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust Builders


First forgive my ignorance, I didn't that the group should only exist in 
the
forest root domain. But how is it possible that CHILDDOMAIN\Incoming 
Forest

Trust Builders has permissions on the child domain in ADUC when there
shouldn't be a CHILDDOMAIN\Incoming Forest Trust Builders?


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matheesha Weerasinghe
Sent: Monday, August 14, 2006 19:37
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest
Trust Builders

Its only in the forest domain IIRC ;-)

M@


On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote:

No??? Child domain.

> -Original Message-
> From: [EMAIL PROTECTED]

> [mailto:[EMAIL PROTECTED] On Behalf Of
> Matheesha Weerasinghe
> Sent: Monday, August 14, 2006 17:38
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest
> Trust Builders
>
> By the way you are looking for this on the forest root right?
>
> M@
>
>
> On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote:
>
>   Yep logged in as Domain Admin.
>
>   > -Original Message- 
>   > From: [EMAIL PROTECTED]

> 
>   > [mailto:[EMAIL PROTECTED]
On Behalf Of
>   > Matheesha Weerasinghe
>   > Sent: Monday, August 14, 2006 13:00
>   > To: ActiveDir@mail.activedir.org
>   > Subject: Re: [ActiveDir] Recreate
BUILTIN\Incoming Forest
>   > Trust Builders
>   >
>   > I am wondering if there are ACLs defined on
the group itself
>   > or the OU above to prevent you from seen it.
Do you see it as
>   > the Administrator account of the domain?
>   >
>   > M@
>   >
>   >
>   > On 8/14/06, Han Valk < [EMAIL PROTECTED]
> mailto:[EMAIL PROTECTED]> > > wrote:
>   >
>   >   Problem is I don't see it anymore in the BUILTIN
>   > container. Strange thing is
>   >   that if I look at the security of the
domain object in
>   > ADUC Incoming Forest
>   >   Trust Builders is there.
>   >
>   >   > -Original Message-
>   >   > From:
[EMAIL PROTECTED]

>   >   > [mailto: [EMAIL PROTECTED]
>   > mailto:[EMAIL PROTECTED]> > ] On Behalf Of
>   >   > Matheesha Weerasinghe
>   >   > Sent: Monday, August 14, 2006 10:22
>   >   > To: ActiveDir@mail.activedir.org

>   >   > Subject: Re: [ActiveDir] Recreate
> BUILTIN\Incoming Forest
>   >   > Trust Builders
>   >   >
>   >   > I dont think so. objectsid attribute
is a systemonly
>   >   > attribute. Personally I am impressed
of that "smart
>   >   > co-worker" that managed to delete it.
> According to the AD
>   >   > Delegation appendices
>   >   >
>   >
http://www.microsoft.com/downloads/details.aspx?FamilyID=29dba
>   >
e88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en >
>   >
>    >
ae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en>  its
>   > not > possible to move
>   >   delete rename this group.
>   >   >
>   >   > May be he exploited the dynamic objects
> feature in Windows
>   >   > 2003 RTM?
>   >   >
>   >
>
http://blogs.dirteam.com/blogs/tomek/archive/2006/06/23/1175.aspx
>   >   >
>   >   >
>   >   > M@
>   >   >
>   >   >
>   >   >
>   >   > On 8/14/06, Han Valk <
[EMAIL PROTECTED]> wrote:
>   >   >
>   >   >   Hi,
>   >   >
>   >   >   A smart co-worker deleted the
> BUILTIN\Incoming Forest
>   >   > Trust Builders group.
>   >   >   Is it possible to recreate this group
> with the same
>   >   > well known SID?
>   >   >   Authoritative restore is out of
the question,
>   >   > deletetion is too long ago.
>   >   >
>   >   >   Han Valk.
>   >   >   List info   :
> http://www.activedir.org/List.aspx
> 
>   >   >   List FAQ:
> http://www.activedir.org/ListFAQ.aspx
>   >   >   List archive:
> http://www.activedir.org/ml/threads.aspx
>

RE: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust Builders

2006-08-17 Thread Dean Wells

I'm not in a position to properly prove-out the existence and/or reason for
the child domain ACEs.  However, the Incoming Forest Trust Builders group
uses a well-known SID of S-1-5-32-557, this kind of SID lacks domain
affiliation, i.e. it doesn't technically belong to any particular domain
within the forest and is subsequently deemed as "mine" by any DC attempting
to resolve it regardless of the domain they're in.  

Note that the same is true to say of Administrators, for example - review
the ACL on the NC head of the ForestDNSzones partition when focused on a
DC/DNS server in the forest root domain, re-read the same ACL when focused
on a DC in a peer-root or child-domain ... note the claimed affiliation of
the Administrators ACE.

--
Dean Wells
MSEtechnology
t Email: [EMAIL PROTECTED]
http://msetechnology.com

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED] On Behalf Of Han Valk
> Sent: Thursday, August 17, 2006 5:25 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust
> Builders
> 
> First forgive my ignorance, I didn't that the group should only exist
> in the forest root domain. But how is it possible that
> CHILDDOMAIN\Incoming Forest Trust Builders has permissions on the child
> domain in ADUC when there shouldn't be a CHILDDOMAIN\Incoming Forest
> Trust Builders?
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha
> > Weerasinghe
> > Sent: Monday, August 14, 2006 19:37
> > To: ActiveDir@mail.activedir.org
> > Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest Trust
> > Builders
> >
> > Its only in the forest domain IIRC ;-)
> >
> > M@
> >
> >
> > On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote:
> >
> > No??? Child domain.
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > 
> > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Matheesha Weerasinghe
> > > Sent: Monday, August 14, 2006 17:38
> > > To: ActiveDir@mail.activedir.org
> > > Subject: Re: [ActiveDir] Recreate BUILTIN\Incoming Forest
> > > Trust Builders
> > >
> > > By the way you are looking for this on the forest root right?
> > >
> > > M@
> > >
> > >
> > > On 8/14/06, Han Valk <[EMAIL PROTECTED]> wrote:
> > >
> > >   Yep logged in as Domain Admin.
> > >
> > >   > -Original Message-
> > >   > From: [EMAIL PROTECTED]
> > > 
> > >   > [mailto:[EMAIL PROTECTED]
> > On Behalf Of
> > >   > Matheesha Weerasinghe
> > >   > Sent: Monday, August 14, 2006 13:00
> > >   > To: ActiveDir@mail.activedir.org
> > >   > Subject: Re: [ActiveDir] Recreate
> > BUILTIN\Incoming Forest
> > >   > Trust Builders
> > >   >
> > >   > I am wondering if there are ACLs defined on
> > the group itself
> > >   > or the OU above to prevent you from seen it.
> > Do you see it as
> > >   > the Administrator account of the domain?
> > >   >
> > >   > M@
> > >   >
> > >   >
> > >   > On 8/14/06, Han Valk < [EMAIL PROTECTED]
> > >  >  > > wrote:
> > >   >
> > >   >   Problem is I don't see it anymore in the BUILTIN
> > >   > container. Strange thing is
> > >   >   that if I look at the security of the
> > domain object in
> > >   > ADUC Incoming Forest
> > >   >   Trust Builders is there.
> > >   >
> > >   >   > -Original Message-
> > >   >   > From:
> > [EMAIL PROTECTED]
> > 
> > >   >   > [mailto: [EMAIL PROTECTED]
> > >   >  >  > ] On Behalf Of
> > >   >   > Matheesha Weerasinghe
> > >   >   > Sent: Monday, August 14, 2006 10:22
> > >   >   > To: ActiveDir@mail.activedir.org
> > 
> > >   >   > Subject: Re: [ActiveDir] Recreate
> > > BUILTIN\Incoming Forest
> > >   >   > Trust Builders
> > >   >   >
> > >   >   > I dont think so. objectsid attribute
> > is a systemonly
> > >   >   > attribute. Personally I am impressed
> > of that "smart
> > >   >   > co-worker" that managed to delete it.
> > > According to the AD
> > >   >   > Delegation appendices
> > >   >   >
> > >   >
> > http://www.microsoft.com/downloads/details.aspx?FamilyID=29dba
> > >   >
> > e88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en >
> > >   >
> > >  > >   >
> > ae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en>  its
> > >   > not > possible to move
> > >   >   del

RE: [ActiveDir] FMSO roles split, patch question.




in addition to that
DC1 having FSMOset1 and DC2 having 
FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event 
logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to 
DC1
apply patches 
to DC2 and reboot and check everything (event logs DCdiag, 
etc)
if everything OK!
transfer FSMOset2 from DC1 to 
DC2
voila (that's 
french)...done! ;-)
 
jorge
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
  AkomolafeSent: Wednesday, August 09, 2006 01:52To: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
  split, patch question.
  
  
  It doesn't 
  matter.
   
  
  
  Sincerely,    
  _    
    (, /  |  
  /)   
  /) /)       /---| 
  (/_  __   ___// _   //  _  ) 
  /    |_/(__(_) // 
  (_(_)(/_(_(_/(__(/_(_/ 
  /)  
     
  (/   Microsoft MVP - Directory 
  Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you 
  were worried about Yesterday? 
  -anon
  
  
  From: John StrongoskySent: Tue 
  8/8/2006 4:49 PMTo: ActiveDir@mail.activedir.orgSubject: 
  [ActiveDir] FMSO roles split, patch question.
  
  We 
  have our FMSO roles split between 2 dc's. They are Schema Master/Domain Tree 
  Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on 
  the other. After I apply the patches from Microsoft what is the beat 
  practices for the boot order...or does it matter?
   
  1. 
  Remote DC/GC's first
  2. 
  no. 1
  3. 
  then no 2.
   
   
  thanks
   
   
   
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

RE: [ActiveDir] Moving Sysvol .




to mitigate that risk you can also place a DUMMY file (lets 
say with the size of something like 1 GB)
 
normally, if the disk with the DIT/SYSVOL fills up you will 
not have any space left to work with or to take any actions so solve the 
problem.
however, if create one (or more) dummy files you can give 
yourself more space if the volume fills up. simply delete the dummy file and you 
can continue for a short while and also giving you time to resolve anything you 
want more easily
I also use this when working with VMs to so some tests 
(sometimes I have multiple VMs on my laptop). As soon as the disk fills the VM 
software complains and if I don't have any spare space left it crashes the VMs 
and the virtual software. I use three dummy files for that, whereas the first 
two are used as a warning.
W2K3 and WXP provide a very nice utility called 
FSUTIL
 
 
For my VMs I use:
CreateBogusFile1_050MB.cmd --> FSUTIL FILE CREATENEW 
E:\VMs\FakeFile1.bogus 5000CreateBogusFile2_100MB.cmd --> FSUTIL FILE CREATENEW 
E:\VMs\FakeFile2.bogus 1CreateBogusFile3_200MB.cmd --> FSUTIL 
FILE CREATENEW E:\VMs\FakeFile3.bogus 2
 
For your DIT/SYSVOL volumes you can so something 
like
FSUTIL FILE CREATENEW 
:\\FakeFile.bogus 10 (= 1 
GB)
the numeric value is specified in KBs
 
jorge

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Darren 
  Mar-EliaSent: Tuesday, August 08, 2006 16:58To: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Moving Sysvol 
  .
  
  Yea, I'm not sure why one has to do with the other (GPO 
  delegation and security of the DIT). GPO delegation simply involves granting 
  permissions on a individual GPC objects in AD and individual folders in the 
  GPT (SYSVOL). The only risk I can see is that it is marginally 
  easier to fill up a disk by writing a ton of data into SYSVOL than 
  it is to do that by generating millions of AD objects (both of which a 
  "lesser" admin can do), but if either happens, you probably have bigger 
  problems than the disk with the DIT on it 
  filling up.
   
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  [EMAIL PROTECTED]Sent: Tuesday, August 08, 2006 6:58 
  AMTo: ActiveDir@mail.activedir.orgSubject: RE: 
  [ActiveDir] Moving Sysvol .
  
  ... but then there's the school of thought that says you 
  should:
   
   - 
  Place DIT and logs on separate spindles, since DIT is read intensive and logs are write intensive
   
  Since SYSVOL is also read intensive, I'd prefer to place SYSVOL with 
  the DIT. 
   
  To 
  be honest, I don't follow the delegation argument...GPOs exists in SYSVOL and 
  AD so if delegating access to GPOs, surely there is an argument for placing 
  SYSVOL and DIT on the *same* disk(?)
   
   
  neil
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Paul 
  WilliamsSent: 08 August 2006 13:35To: 
  ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Moving Sysvol 
  .
  
  Yes, you can relocate the SYSVOL.  
  It's just a little more involved (couple of extra steps, not difficult) than 
  moving the DIT.  See:
   -- http://support.microsoft.com/?id=842162
   
   
  However, if I might be so bold as to 
  make a suggestion here, I would recommed you leave SYSVOL where it is, giving 
  you:
   
  0: Windows
  1: DIT and Logs
  2: SYSVOL
   
   
  You don't want SYSVOL on the same disk 
  as the database.  Especially if you are delegating things like GPO 
  modification, etc. to non-admins or lesser admins.
   
   
  --Paul
  
- Original Message - 
From: 
Yann 
To: ActiveDir@mail.activedir.org 

Sent: Tuesday, August 08, 2006 1:14 
PM
Subject: [ActiveDir] Moving Sysvol 
.

Hello :)
 
I have my AD w2k3sp1 hard disk configured as this:
hdd1: AD logs.
hdd2: ntds.dit + sysvol.
 
I would like to change my hdd2, so i move the ntds.dit in hdd1 and 
that's ok. But how to move the sysvol folder in hdd1 ? is there a way to do 
this ?
 
Thanks for your replies.
 
Yann
 


Découvrez un nouveau moyen de poser toutes vos questions quelque soit le 
sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos 
opinions et vos expériences. Cliquez 
ici. 
  PLEASE READ: The 
  information contained in this email is confidential and 
  intended for the 
  named recipient(s) only. If you are not an intended 
  recipient of this 
  email please notify the sender immediately and delete your 

  copy from your 
  system. You must not copy, distribute or take any further 
  action in reliance 
  on it. Email is not a secure method of communication and 
  Nomura 
  International plc ('NIplc') will not, to the extent permitted by law, 
  
  accept 
  responsibility or liability for (a) the accuracy or completeness of, 
  
  or (b) the 
  presence of any virus, worm or similar malicious or disabling 
  
  code in, this 
  messa

RE: [ActiveDir] Setting FFL=2 automatically when building first DC in forest

Title: Setting FFL=2 automatically when building first DC in forest

Perhaps another change request for Longhorn? :)
already has
it!
DCPROMO contains a
crap load of new switches for an answer file but also as arguments for
DCPROMO
jorge

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Thursday, August 03, 2006
10:40To: ActiveDir@mail.activedir.orgSubject:
[ActiveDir] Setting FFL=2 automatically when building first DC in
forest

According to http://support.microsoft.com/kb/223757/en-us the SetForestVersion entry
in the dcpromo answer file can only be used to set FFL to 1 or 0 when building
a new forest.
Is this correct? I'd like to automate the
transition to FFL=2 when building the first DC in a forest (without a
script).
Perhaps another change request for Longhorn?
:)
neil
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your

copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura
International plc ('NIplc') will not, to the extent permitted by law,

accept
responsibility or liability for (a) the accuracy or completeness of,

or (b) the
presence of any virus, worm or similar malicious or disabling

code in, this
message or any attachment(s) to it. If verification of this

email is sought
then please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment
research; (2) contains views or opinions that are solely those of

the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or

offer to buy or
sell securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT
No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,

London, EC1A 4NP.
A member of the Nomura group of companies.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

RE: [ActiveDir] Adding a 2003 Server to AD2000




see:
http://blogs.dirteam.com/blogs/jorge/archive/2005/11/19/110.aspx
 
jorge

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Chris 
  PohlschneiderSent: Friday, August 11, 2006 20:05To: 
  ActiveDir@mail.activedir.orgSubject: [ActiveDir] Adding a 2003 
  Server to AD2000
  
  
  What is the process of adding in a 
  Windows Server 2003 DC into an existing Windows 2000 AD? Do we have to run the 
  2003 Server CD on the 2000 domain controllers and run the adprep and forest 
  prep? Thanks for any help.
   
  Chris 
  Pohlschneider
  Holloway 
  Sportswear IT
  937-494-2559
  937-497-7300 
  (Fax)
  [EMAIL PROTECTED]
   
   
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

RE: [ActiveDir] backup and restore AD.

when a DC is restored from the system state (amongst
others):
* the restored RID pool is thrown away (invalidated) and a
new RID pool is requested at the RID master
* the invocation ID of the AD DB is changed (which prevent
USN rollbacks)
so in your case it works because the backup is not that
old. The AD DB is tightly coupled with the registry and there is a reason for
that! The reason as why you MUST restore the system state as MS says. The way
you are doing that is, how shall I say it gentlyNOT SUPPORTED!
;-)
And I guess you will be hitting on USN Rollback. See my
blog and search for BACKUP and you will find an article with some more
info
jorge

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
YannSent: Tuesday, August 08, 2006 22:47To:
ActiveDir@mail.activedir.orgSubject: [ActiveDir] backup and restore
AD.

Hello,
I had question about D backup & restore.
It is possible to backup AD in 2 ways:
1) backup only the system state.
2) backup system state & file system containing the AD working
directory (ntds.dit, edb.chk, Edb*.log,Res1.log and Res2.log).
MS states that u have to restore your AD by restoring the system
state.
But ,what about just restoring the AD working directory without
system state ? I tested it and that works fine.
So my question is:
=> In what circumstances do i have to choose a restore from system
state or a restore from AD working directory.
Thanks for clarification,
Yann

Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet
! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et
vos expériences. Cliquez
ici.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

RE: [ActiveDir] Netlogon and SYSVOL after Restore




see my blog which contains an article about kicking NTFRS 
(SYSVOL) to replicate after a non-auth rest of the SYSTEM 
STATE.
Make sure the partner you specify in the registry key is 
also the partner that is used in one of the inbound COs of the restored DC as it 
otherwise does not work (this is not mentioned in my post and therefore I need 
to update it)
 
jorge

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Salandra, 
  Justin A.Sent: Thursday, August 10, 2006 15:41To: 
  ActiveDir@mail.activedir.orgCc: Barnett, BernardSubject: 
  [ActiveDir] Netlogon and SYSVOL after Restore
  
  
  We have restored a Domain 
  Controller and on reboot we noticed that the Netlogon, and the SYSVOL folders 
  exists but are not shared.  Is this normal, should we share them out 
  ourselves or will it happen automatically?
   
  Justin A. 
  Salandra
  MCSE Windows 2000 & 
  2003
  Network and Technology Services 
  Manager
  Catholic Healthcare 
  System
  646.505.3681 - 
  office
  917.455.0110 - 
  cell
  [EMAIL PROTECTED]
   
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[ActiveDir] w2k3 dcpromo failure

2006-08-17 Thread Al Lilianstrom

We're in the process of replacing our w2k DCs with w2k3 machines. 
Forestprep and domainprep went fine as well as putting the first new 
w2k3 DC up.


Yesterday we demoted one of the old w2k machines and removed it from the 
domain. Configured a w2k3 server with the same name and IP and ran 
dcpromo when it was a workgroup member. About 6 minutes into the process 
 this event showed up in the directory service log




Event Type: Error
Event Source:   NTDS General
Event Category: Internal Processing
Event ID:   1168
Date:   8/16/2006
Time:   2:06:35 PM
User:   NT AUTHORITY\ANONYMOUS LOGON
Computer:   BIRD
Description: Internal error: An Active Directory error has occurred.

Additional Data
Error value (decimal): -1073741823
Error value (hex): c001
Internal ID: 3000e54

and then this

Event Type: Information
Event Source:   NTDS Setup
Event Category: Setup
Event ID:   1442
Date:   8/16/2006
Time:   2:06:57 PM
User:   N/A
Computer:   BIRD
Description:
During the cleanup operation of a failed Active Directory installation, 
the NTDS Settings object for the local server could not be deleted from 
the remote domain controller.


Server:
CN=BIRD,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=wn,DC=fnal,DC=gov 


Remote domain controller: lbird.wn.fnal.gov

User Action
Delete this object manually using Active Directory Sites and Services.

Additional Data
Error value: The RPC server is unavailable. 1722



The server ended up being non responsive and required a reboot.

I've been doing some research and I can' find answers to a a couple of 
questions:


1) Would starting the dcpromo process with the server not in the domain 
have caused this? I've always added the machine to the domain before 
promotion. The admin who attempted the promotion said he has done it 
this way before.


2) When deleting the object from AD (as specified above) the option that 
actually deletes the object states that the DC is permanently offline 
and can no longer be demoted... Does chosing this option prevent me from 
adding the DC with the same name (Like seizing FSMO roles) ?


al

--

Al Lilianstrom
CD/CSS/CSI
[EMAIL PROTECTED]
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

RE: [ActiveDir] w2k3 dcpromo failure

after demotion you still need to delete the server object manually in sites and 
services (this is normal) (everything else like computer account, frs stuff and 
ntds settings is removed by dcpromo)
 
1) you can promote servers to DCs while they are member of a domain or not. it 
does not matter. the only difference is during DCPROMO. if the server is 
already a member then that step is skipped
 
2) if the NTDS setting is still there the demotion was not successful. perform 
a metadata cleanup first before promoting the other server to a DC 
(http://blogs.dirteam.com/blogs/jorge/archive/2005/12/03/213.aspx)
 
Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of Al Lilianstrom
Sent: Thu 2006-08-17 14:36
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] w2k3 dcpromo failure



We're in the process of replacing our w2k DCs with w2k3 machines.
Forestprep and domainprep went fine as well as putting the first new
w2k3 DC up.

Yesterday we demoted one of the old w2k machines and removed it from the
domain. Configured a w2k3 server with the same name and IP and ran
dcpromo when it was a workgroup member. About 6 minutes into the process
  this event showed up in the directory service log



Event Type: Error
Event Source:   NTDS General
Event Category: Internal Processing
Event ID:   1168
Date:   8/16/2006
Time:   2:06:35 PM
User:   NT AUTHORITY\ANONYMOUS LOGON
Computer:   BIRD
Description: Internal error: An Active Directory error has occurred.

Additional Data
Error value (decimal): -1073741823
Error value (hex): c001
Internal ID: 3000e54

and then this

Event Type: Information
Event Source:   NTDS Setup
Event Category: Setup
Event ID:   1442
Date:   8/16/2006
Time:   2:06:57 PM
User:   N/A
Computer:   BIRD
Description:
During the cleanup operation of a failed Active Directory installation,
the NTDS Settings object for the local server could not be deleted from
the remote domain controller.

Server:
CN=BIRD,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=wn,DC=fnal,DC=gov

Remote domain controller: lbird.wn.fnal.gov

User Action
Delete this object manually using Active Directory Sites and Services.

Additional Data
Error value: The RPC server is unavailable. 1722



The server ended up being non responsive and required a reboot.

I've been doing some research and I can' find answers to a a couple of
questions:

1) Would starting the dcpromo process with the server not in the domain
have caused this? I've always added the machine to the domain before
promotion. The admin who attempted the promotion said he has done it
this way before.

2) When deleting the object from AD (as specified above) the option that
actually deletes the object states that the DC is permanently offline
and can no longer be demoted... Does chosing this option prevent me from
adding the DC with the same name (Like seizing FSMO roles) ?

al

--

Al Lilianstrom
CD/CSS/CSI
[EMAIL PROTECTED]
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx




This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.
<>

RE: [ActiveDir] LDAP Logon Name




I'm sorry small correction... 
 
You have two different things you have to worry about 
special characters in, DNs and Search Filters. They have different sets of 
characters you need to worry about and also have two different methods of 
escaping the characters. 
 
In DNs you escape special characters by a preceding back 
slash, note from RFC 2253:
 
   If the UTF-8 string does not have any of the following 
characters   which need escaping, then that string can be used as 
the string   representation of the 
value.    o   a space or "#" character 
occurring at the beginning of the    
string    o   a space character occurring at 
the end of the string    o   one of the 
characters ",", "+", """, "\", "<", ">" or ";"   
Implementations MAY escape other characters.   If a character 
to be escaped is one of the list shown above, then it   is 
prefixed by a backslash ('\' ASCII 92).   Otherwise the 
character to be escaped is replaced by a backslash and   two hex 
digits, which form a single byte in the code of the   
character.
As you can see, commas are clearly listed as a character 
that needs to be escaped and this is obvious as Paul mentioned, it is a 
delimitr. It is used to delimit the DN into its individual 
RDNs. 
 
In Search Filters, you have slightly different rules as 
indicated in RFC 2254:
 
If a 
value should contain any of the following 
characters   
Character   ASCII 
value   
---   
*   
0x2a   
(   
0x28   
)   
0x29   
\   
0x5c   
NUL 
0x00   the character must be encoded as the backslash '\' 
character (ASCII   0x5c) followed by the two hexadecimal digits 
representing the ASCII   value of the encoded character. The case 
of the two hexadecimal   digits is not 
significant.   This simple escaping mechanism eliminates 
filter-parsing ambiguities   and allows any filter that can be 
represented in LDAP to be   represented as a NUL-terminated 
string. Other characters besides the   ones listed above may be 
escaped using this mechanism, for example,   non-printing 
characters.   For example, the filter checking whether the 
"cn" attribute contained   a value with the character "*" anywhere 
in it would be represented as   "(cn=*\2a*)".   
Note that although both the substring and present productions in 
the   grammar above can produce the "attr=*" construct, this 
construct is   used only to denote a presence 
filter.
 
As you can see, commas are not normally a character that 
needs to be escaped in a filter. However, they will, because of RFC2253 have to 
be escaped for any attributes with a DN based attribute syntax (i.e. if you 
stuff a DN into a string value, you wouldn't need to escape it, but if you stuff 
it into a DN attribute you would). If you truly were going to escape a comma for 
a filter reason, the escape sequence would be \2c I believe. 

 
To further complicate the matter, putting that slash in 
front of the comma when it isn't required for a DN will cause the filter to not 
properly match.
 
[Thu 08/17/2006 
10:01:46.40]F:\DEV\cpp\eventiddmp>adfind -default -f "displayname=user, 
test" -dn
 
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) 
March 2006
 
Using server: r2dc2.test.loc:389Directory: Windows 
Server 2003Base DN: DC=test,DC=loc
 
dn:CN=user\, 
test,OU=Users,OU=TestOU,DC=test,DC=loc
 
1 Objects returned
 
[Thu 08/17/2006 
10:01:48.69]F:\DEV\cpp\eventiddmp>adfind -default -f "displayname=user\, 
test" -dn
 
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) 
March 2006
 
Using server: r2dc2.test.loc:389Directory: Windows 
Server 2003Base DN: DC=test,DC=loc
 
0 Objects 
returned
 
 
So the upshot, if your query has a DN in it and being 
compared against a DN syntax attribute say like member or memberof, then you 
need to escape any extraneous commas. Otherwise, leave the commas 
alone.
 
This one of the reasons why DNs should be based on very 
simple ascii characters. If using full blown GUI tools they will "usually" 
handle this stuff for you so you don't have to worry, but lower level tools and 
command line tools won't usually guide you as much. 
 
   joe
 
 
 

--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Paul 
WilliamsSent: Thursday, August 17, 2006 4:30 AMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] LDAP Logon 
Name

You need to escape the comma, as a comma 
is a delimiter and in the case of displayName it shouldn't be a 
delimiter:
 
(&(objectCategory=person)(objectClass=user)(displayName=phelps\, 
k*))
 
 
I've not read the whole thread, so can't 
discuss whether or not this is the best way to do what you want.  I will 
say I feel for you re. the HP documentation.  I had some fun getting the AD 
iLO integration stuff to work because the guide wasn't very helpful at 
explaining what f

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread John Strongosky




I 
cornfused is this a standard practice as I thought you did not want to move the 
FMSO roles back and forth. 
 
john


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge deSent: Thursday, August 17, 2006 4:33 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
split, patch question.

in addition to that
DC1 having FSMOset1 and DC2 having 
FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event 
logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to 
DC1
apply patches 
to DC2 and reboot and check everything (event logs DCdiag, 
etc)
if everything OK!
transfer FSMOset2 from DC1 to 
DC2
voila (that's 
french)...done! ;-)
 
jorge
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
  AkomolafeSent: Wednesday, August 09, 2006 01:52To: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
  split, patch question.
  
  
  It doesn't 
  matter.
   
  
  
  Sincerely,    
  _    
    (, /  |  
  /)   
  /) /)       /---| 
  (/_  __   ___// _   //  _  ) 
  /    |_/(__(_) // 
  (_(_)(/_(_(_/(__(/_(_/ 
  /)  
     
  (/   Microsoft MVP - Directory 
  Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you 
  were worried about Yesterday? 
  -anon
  
  
  From: John StrongoskySent: Tue 
  8/8/2006 4:49 PMTo: ActiveDir@mail.activedir.orgSubject: 
  [ActiveDir] FMSO roles split, patch question.
  
  We 
  have our FMSO roles split between 2 dc's. They are Schema Master/Domain Tree 
  Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on 
  the other. After I apply the patches from Microsoft what is the beat 
  practices for the boot order...or does it matter?
   
  1. 
  Remote DC/GC's first
  2. 
  no. 1
  3. 
  then no 2.
   
   
  thanks
   
   
   
This e-mail and any 
attachment is for authorised use by the intended recipient(s) only. It may 
contain proprietary material, confidential information and/or be subject to 
legal privilege. It should not be copied, disclosed to, retained or used by, any 
other party. If you are not an intended recipient then please promptly delete 
this e-mail and any attachment and all copies and inform the sender. Thank 
you.

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

the reason is that is a DC dies during the patching you do not have to seize 
the rolesIMHO, I prefer transfering over seizing
 
Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not want to move 
the FMSO roles back and forth. 
 
john



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge de
Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)
 
jorge

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
Akomolafe
Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.
 


Sincerely, 
   _
  (, /  |  /)   /) /)   
/---| (/_  __   ___// _   //  _ 
 ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)  
   (/   
Microsoft MVP - Directory Services
www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon



From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema 
Master/Domain Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid 
Pool/Intrastate on the other. After I apply the patches from Microsoft what is 
the beat practices for the boot order...or does it matter?
 
1. Remote DC/GC's first
2. no. 1
3. then no 2.
 
 
thanks
 
 
 



This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

<>

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread John Strongosky




Makes 
sensehow many dc's do you have in you 
infrastructure...


From: Almeida Pinto, Jorge de 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge deSent: Thursday, August 17, 2006 8:02 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
split, patch question.


the reason is that is a DC 
dies during the patching you do not have to seize the rolesIMHO, I prefer 
transfering over seizing
 


Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 

LogicaCMG 
Nederland B.V. (BU RTINC Eindhoven)
(   Tel 
: +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 


From: [EMAIL PROTECTED] on 
behalf of John StrongoskySent: Thu 2006-08-17 16:55To: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
split, patch question.

I 
cornfused is this a standard practice as I thought you did not want to move the 
FMSO roles back and forth. 
 
john


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge deSent: Thursday, August 17, 2006 4:33 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
split, patch question.

in addition to that
DC1 having FSMOset1 and DC2 having 
FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event 
logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to 
DC1
apply patches 
to DC2 and reboot and check everything (event logs DCdiag, 
etc)
if everything OK!
transfer FSMOset2 from DC1 to 
DC2
voila (that's 
french)...done! ;-)
 
jorge
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
  AkomolafeSent: Wednesday, August 09, 2006 01:52To: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
  split, patch question.
  
  
  It doesn't 
  matter.
   
  
  
  Sincerely,    
  _    
    (, /  |  
  /)   
  /) /)       /---| 
  (/_  __   ___// _   //  _  ) 
  /    |_/(__(_) // 
  (_(_)(/_(_(_/(__(/_(_/ 
  /)  
     
  (/   Microsoft MVP - Directory 
  Serviceswww.akomolafe.com - we know 
  IT-5.75, -3.23Do 
  you now realize that Today is the Tomorrow you were worried about Yesterday? 
  -anon
  
  
  From: John StrongoskySent: Tue 
  8/8/2006 4:49 PMTo: ActiveDir@mail.activedir.orgSubject: 
  [ActiveDir] FMSO roles split, patch question.
  
  We 
  have our FMSO roles split between 2 dc's. They are Schema Master/Domain Tree 
  Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on 
  the other. After I apply the patches from Microsoft what is the beat 
  practices for the boot order...or does it matter?
   
  1. 
  Remote DC/GC's first
  2. 
  no. 1
  3. 
  then no 2.
   
   
  thanks
   
   
   
This e-mail and any 
attachment is for authorised use by the intended recipient(s) only. It may 
contain proprietary material, confidential information and/or be subject to 
legal privilege. It should not be copied, disclosed to, retained or used by, any 
other party. If you are not an intended recipient then please promptly delete 
this e-mail and any attachment and all copies and inform the sender. Thank 
you.

[ActiveDir] [OT] Longhorn Beta

2006-08-17 Thread WATSON, BEN









Outside of my MSDN account is there a preferred way to
obtain Longhorn Beta’s for testing?

 

~Ben

RE: [ActiveDir] [OT] Longhorn Beta

2006-08-17 Thread Darren Mar-Elia




bit torrent? (just kidding)


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, 
BENSent: Thursday, August 17, 2006 8:35 AMTo: 
ActiveDir@mail.activedir.orgSubject: [ActiveDir] [OT] Longhorn 
Beta


Outside of my MSDN account is there 
a preferred way to obtain Longhorn Beta’s for 
testing?
 
~Ben

Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen 
a "patch" kill a server.


Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.


But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.


Almeida Pinto, Jorge de wrote:

the reason is that is a DC dies during the patching you do not have to seize 
the rolesIMHO, I prefer transfering over seizing
 
Met vriendelijke groeten / Kind regards,

Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)

(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not want to move the FMSO roles back and forth. 
 
john




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge de
Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)
 
jorge


 




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
Akomolafe
Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.
	 
	


	Sincerely, 
	   _
	  (, /  |  /)   /) /)   
	/---| (/_  __   ___// _   //  _ 
	 ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
	(_/ /)  
	   (/   
	Microsoft MVP - Directory Services

www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon



From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema 
Master/Domain Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid 
Pool/Intrastate on the other. After I apply the patches from Microsoft what is 
the beat practices for the boot order...or does it matter?
	 
	1. Remote DC/GC's first

2. no. 1
3. then no 2.
	 
	 
	thanks
	 
	 
	 




This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

  


--
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.activedir.org/ml/threads.aspx

RE: [ActiveDir] FMSO roles split, patch question.




This will be one of the rare occassions I disagree with Jorge. I see no usefulness in this ping pong exercise. DC dies in the process of patching and it is the one holding a specific FSMO role. So what? Just seize the role and wipe the server and do your cleanup and reinstall.
 
Due dilligence is to test your patches and ensure that they don't take your servers/infrastructure down before you proceed with deploying them on your live environment.
 


Sincerely,    _      (, /  |  /)   /) /)       /---| (/_  __   ___// _   //  _  ) /    |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /)     (/   Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon


From: Almeida Pinto, Jorge deSent: Thu 8/17/2006 8:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.


the reason is that is a DC dies during the patching you do not have to seize the rolesIMHO, I prefer transfering over seizing
 


Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 

LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 


From: [EMAIL PROTECTED] on behalf of John StrongoskySent: Thu 2006-08-17 16:55To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.

I cornfused is this a standard practice as I thought you did not want to move the FMSO roles back and forth. 
 
john


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Thursday, August 17, 2006 4:33 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.

in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, etc)
if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)
 
jorge
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji AkomolafeSent: Wednesday, August 09, 2006 01:52To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.
 


Sincerely,    _      (, /  |  /)   /) /)       /---| (/_  __   ___// _   //  _  ) /    |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /)     (/   Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon


From: John StrongoskySent: Tue 8/8/2006 4:49 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] FMSO roles split, patch question.

We have our FMSO roles split between 2 dc's. They are Schema Master/Domain Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on the other. After I apply the patches from Microsoft what is the beat practices for the boot order...or does it matter?
 
1. Remote DC/GC's first
2. no. 1
3. then no 2.
 
 
thanks
 
 
 
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Re: [ActiveDir] [OT] Longhorn Beta

2006-08-17 Thread Matheesha Weerasinghe


Technet Plus

On 8/17/06, WATSON, BEN <[EMAIL PROTECTED]> wrote:




Outside of my MSDN account is there a preferred way to obtain Longhorn
Beta's for testing?



~Ben

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

RE: [ActiveDir] FMSO roles split, patch question.

I completely concur with Jorge on his process. 

It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 

Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 

 joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen 
a "patch" kill a server.

Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.

But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.

Almeida Pinto, Jorge de wrote:
> the reason is that is a DC dies during the patching you do not have to
seize the rolesIMHO, I prefer transfering over seizing
>  
> Met vriendelijke groeten / Kind regards,
> Ing. Jorge de Almeida Pinto
> Senior Infrastructure Consultant
> MVP Windows Server - Directory Services
>  
> LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
> (   Tel : +31-(0)40-29.57.777
> (   Mobile : +31-(0)6-26.26.62.80
> *   E-mail : 
>
> 
>
> From: [EMAIL PROTECTED] on behalf of John Strongosky
> Sent: Thu 2006-08-17 16:55
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> I cornfused is this a standard practice as I thought you did not want to
move the FMSO roles back and forth. 
>  
> john
>
> 
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
Jorge de
> Sent: Thursday, August 17, 2006 4:33 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> in addition to that
> DC1 having FSMOset1 and DC2 having FSMOset2
> transfer FSMOset1 from DC1 to DC2
> apply patches to DC1 and reboot and check everything (event logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset1 and FSMOset2 from DC2 to DC1
> apply patches to DC2 and reboot and check everything (event logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset2 from DC1 to DC2
> voila (that's french)...done! ;-)
>  
> jorge
>
>  
>
> 
>
>   From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
>   Sent: Wednesday, August 09, 2006 01:52
>   To: ActiveDir@mail.activedir.org
>   Subject: RE: [ActiveDir] FMSO roles split, patch question.
>   
>   
>   It doesn't matter.
>
>   
>
>   Sincerely, 
>  _
> (, /  |  /)   /) /)   
>   /---| (/_  __   ___// _   //  _ 
>) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
>   (_/ /)  
>  (/   
>   Microsoft MVP - Directory Services
>   www.akomolafe.com - we know IT
>   -5.75, -3.23
>   Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
>
> 
>
>   From: John Strongosky
>   Sent: Tue 8/8/2006 4:49 PM
>   To: ActiveDir@mail.activedir.org
>   Subject: [ActiveDir] FMSO roles split, patch question.
>   
>   
>   We have our FMSO roles split between 2 dc's. They are Schema
Master/Domain Tree Operator on 1 and on 2,  the

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread John Strongosky

Whets the time interval on moving these before you patch the DC's that the
roles were on.

john

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, August 17, 2006 9:32 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.

I completely concur with Jorge on his process. 

It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 

Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 

 joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen a
"patch" kill a server.

Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they
would find ahead of time if basic functionality of a DC would be nailed.

But if the server dies... it was probably on the emergency list prior to
patching.  Rebooting the box first ensures that you find these 'hospital
bound' servers.

Almeida Pinto, Jorge de wrote:
> the reason is that is a DC dies during the patching you do not have to
seize the rolesIMHO, I prefer transfering over seizing
>  
> Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto 
> Senior Infrastructure Consultant MVP Windows Server - Directory 
> Services
>  
> LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
> (   Tel : +31-(0)40-29.57.777
> (   Mobile : +31-(0)6-26.26.62.80
> *   E-mail : 
>
> 
>
> From: [EMAIL PROTECTED] on behalf of John Strongosky
> Sent: Thu 2006-08-17 16:55
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> I cornfused is this a standard practice as I thought you did not want 
> to
move the FMSO roles back and forth. 
>  
> john
>
> 
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
Jorge de
> Sent: Thursday, August 17, 2006 4:33 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> in addition to that
> DC1 having FSMOset1 and DC2 having FSMOset2 transfer FSMOset1 from DC1 
> to DC2 apply patches to DC1 and reboot and check everything (event 
> logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset1 and FSMOset2 from DC2 to DC1 apply patches to DC2 
> and reboot and check everything (event logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset2 from DC1 to DC2
> voila (that's french)...done! ;-)
>  
> jorge
>
>  
>
> 
>
>   From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
>   Sent: Wednesday, August 09, 2006 01:52
>   To: ActiveDir@mail.activedir.org
>   Subject: RE: [ActiveDir] FMSO roles split, patch question.
>   
>   
>   It doesn't matter.
>
>   
>
>   Sincerely, 
>  _
> (, /  |  /)   /) /)   
>   /---| (/_  __   ___// _   //  _ 
>) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
>   (_/ /)  
>  (/   
>   Microsoft MVP - Directory Services
>   www.akomolafe.com - we know IT
>   -5.75, -3.23
>   Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
>
> _

Re: [ActiveDir] FMSO roles split, patch question.

Valid point.  But you should [try and] restore from the backup that ran the 
night before and that you verified successfully completed before you applied 
the patch...   ;-)


If you have a document process that goes through the proper change control, 
then there shouldn't be any reason to do this.  The patches should be tested 
in dev and pre-prod and then applied, only if there's a rollback option, and 
that should be something like "uninstall patch; restore from last night's 
successful back if unable to boot and uninstall".



--Paul

- Original Message - 
From: "Almeida Pinto, Jorge de" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 17, 2006 4:02 PM
Subject: RE: [ActiveDir] FMSO roles split, patch question.


the reason is that is a DC dies during the patching you do not have to seize 
the rolesIMHO, I prefer transfering over seizing


Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services

LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not want to 
move the FMSO roles back and forth.


john



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge de

Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, 
etc)

if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, 
etc)

if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)

jorge





From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe

Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.



Sincerely,
  _
 (, /  |  /)   /) /)
   /---| (/_  __   ___// _   //  _
) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
  (/
Microsoft MVP - Directory Services
www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon




From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema Master/Domain 
Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on 
the other. After I apply the patches from Microsoft what is the beat 
practices for the boot order...or does it matter?


1. Remote DC/GC's first
2. no. 1
3. then no 2.


thanks






This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an 
intended recipient then please promptly delete this e-mail and any 
attachment and all copies and inform the sender. Thank you.



List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Re: [ActiveDir] FMSO roles split, patch question.

I have.  When bulk-patching NT 4 servers several died (OS was trashed, not 
the h/w) and had to be restored from the backup the night before.


There was that issue where the patch wrote ntoskrnl beyond the 7.8 GB 
section of the disk, although that hit workstations more than servers as 
they'd been build from images and had bigger disks than NT 4 boot loader 
could cope with .



--Paul

- Original Message - 
From: "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" 
<[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 17, 2006 4:47 PM
Subject: Re: [ActiveDir] FMSO roles split, patch question.


As a person who tests/patches a bunch of single DCs I've never seen a 
"patch" kill a server.


Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.


But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.


Almeida Pinto, Jorge de wrote:
the reason is that is a DC dies during the patching you do not have to 
seize the rolesIMHO, I prefer transfering over seizing

 Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not want to 
move the FMSO roles back and forth. john




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge de

Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, 
etc)

if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, 
etc)

if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)
 jorge




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe

Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.


Sincerely, _(, /  |  /) 
/) /)   /---| (/_  __   ___// _   //  _ ) /|_/(__(_) // 
(_(_)(/_(_(_/(__(/_
(_/ /)  (/   Microsoft MVP - 
Directory Services

www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon




From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema 
Master/Domain Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid 
Pool/Intrastate on the other. After I apply the patches from Microsoft 
what is the beat practices for the boot order...or does it matter?


1. Remote DC/GC's first
2. no. 1
3. then no 2.


thanks





This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be 
copied, disclosed to, retained or used by, any other party. If you are 
not an intended recipient then please promptly delete this e-mail and any 
attachment and all copies and inform the sender. Thank you.





--
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.activedir.org/ml/threads.aspx 


List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Re: [ActiveDir] [OT] Longhorn Beta

2006-08-17 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]




http://connect.microsoft.com/
 
 
--Paul

  - Original Message - 
  From: 
  WATSON, 
  BEN 
  To: ActiveDir@mail.activedir.org 
  
  Sent: Thursday, August 17, 2006 4:35 
  PM
  Subject: [ActiveDir] [OT] Longhorn 
  Beta
  
  
  Outside of my MSDN account is 
  there a preferred way to obtain Longhorn Betas for 
  testing?
   
  ~Ben

Re: [ActiveDir] FMSO roles split, patch question.


Skid marks?

More like blood, guts, gore and medics yelling "Triage!"

I can tell you though that we've had way more issues installing service 
packs than patches though.  Gimme a patch Tuesday and I don't blink an 
eye. hand me a service pack and I'm not looking forward to it.


SBS 4.5 we lost Internet connectivity on that box with a RRAS patch eons 
ago and that's .to the best of my knowledge the last time a 
patch nailed our servers so hard they lost major parts of their job 
description.


Normally if we lose the DC, there's some other fundamental reason for 
the loss and it's not necessarily patch related.  I am seeing desktop 
and app impact these days... Incidents.org has put up a nice grid 
tracking the known issues in the patches this month:


Microsoft August 2006 Patches: STATUS
 http://isc.sans.org/diary.php?n&storyid=1611 



So far desktops are getting the worst of it.

(as a FYI SBS has to be the PDC, hold the FSMO roles, if the FSMO roles 
are not held by the SBS box we have this slightly nasty habit of having 
this sbscore service enforce our limitations and force a shut down every 
hour on the hour.thus ... while transferring/seizing is best 
practice for you guys... I'd advise anyone patching SBS networks to not 
do that)
Windows 2003 Small Business Server Shuts Down Unexpectedly; Events 1001, 
1013 and 1014 are Logged:

http://support.microsoft.com/kb/555087


Also a bit OT:  but check out the SCE blog and all the new betas on the 
renamed MOM stuff... sounding cool if they pull it off...


System Center Essentials Product Team Blog:
http://blogs.technet.com/caseymck/default.aspx

The team is hard at work on the System Center Essentials public beta 
release.  Expect to see a link to the install bits in a few weeks.


This public beta enables almost all of our core product scenarios:

1- Comprehensive monitoring of servers and clients
2- Update and Patch Deployment (of Microsoft and Third Party apps)
3- Software Distribution (MSI and EXE-based apps)
4- Software & Hardware Inventory
5- Remote Managed Services (for service providers)

Looking forward to customer feedback, feel free to post it to this blog 
when you can.







joe wrote:
I completely concur with Jorge on his process. 


It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 


Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 


 joe


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen 
a "patch" kill a server.


Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.


But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.


Almeida Pinto, Jorge de wrote:
  

the reason is that is a DC dies during the patching you do not have to


seize the rolesIMHO, I prefer transfering over seizing
  
 
Met vriendelijke groeten / Kind regards,

Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)

(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 

_

RE: [ActiveDir] [OT] Longhorn Beta

2006-08-17 Thread WATSON, BEN









That was definitely the first place I
checked, and unless I’m blind (which I’ve been accused of many
times by the way), I don’t believe it’s an available option on the
connect website to test.

 

I’ll probably end up just using my
MSDN copy in our test environment to create a Longhorn DC.

 









From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams
Sent: Thursday, August 17, 2006
10:01 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] [OT]
Longhorn Beta



 



http://connect.microsoft.com/





 





 





--Paul







- Original Message - 





From: WATSON, BEN






To: ActiveDir@mail.activedir.org






Sent: Thursday, August
17, 2006 4:35 PM





Subject: [ActiveDir] [OT]
Longhorn Beta





 



Outside of my MSDN account is there a preferred way to obtain
Longhorn Beta’s for testing?

 

~Ben

Re: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]


NT 4.0?

'nuff said.

NT should be killed off.  :-)

The patching mechanisms of the NT 4.0 era is not the patch mechanisms of 
today.  We've gone from like 8 patch engines down to 2.  We didn't have 
patch Tuesday when NT was built.


Paul Williams wrote:
I have.  When bulk-patching NT 4 servers several died (OS was trashed, 
not the h/w) and had to be restored from the backup the night before.


There was that issue where the patch wrote ntoskrnl beyond the 7.8 GB 
section of the disk, although that hit workstations more than servers 
as they'd been build from images and had bigger disks than NT 4 boot 
loader could cope with .



--Paul

- Original Message - From: "Susan Bradley, CPA aka Ebitz - SBS 
Rocks [MVP]" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 17, 2006 4:47 PM
Subject: Re: [ActiveDir] FMSO roles split, patch question.


As a person who tests/patches a bunch of single DCs I've never 
seen a "patch" kill a server.


Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and 
they would find ahead of time if basic functionality of a DC would be 
nailed.


But if the server dies... it was probably on the emergency list prior 
to patching.  Rebooting the box first ensures that you find these 
'hospital bound' servers.


Almeida Pinto, Jorge de wrote:
the reason is that is a DC dies during the patching you do not have 
to seize the rolesIMHO, I prefer transfering over seizing

 Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not 
want to move the FMSO roles back and forth. john




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida 
Pinto, Jorge de

Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs 
DCdiag, etc)

if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs 
DCdiag, etc)

if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)
 jorge




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe

Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.


Sincerely, _(, /  |  /) /) 
/)   /---| (/_  __   ___// _   //  _ ) /|_/(__(_) // 
(_(_)(/_(_(_/(__(/_
(_/ /)  (/   Microsoft MVP - 
Directory Services

www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon




From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema 
Master/Domain Tree Operator on 1 and on 2,  the roles PDC 
Emulator/Rid Pool/Intrastate on the other. After I apply the patches 
from Microsoft what is the beat practices for the boot order...or 
does it matter?


1. Remote DC/GC's first
2. no. 1
3. then no 2.


thanks





This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be 
copied, disclosed to, retained or used by, any other party. If you 
are not an intended recipient then please promptly delete this 
e-mail and any attachment and all copies and inform the sender. 
Thank you.





--
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.activedir.org/ml/threads.aspx 


List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx



--
Letting your vendors set your risk analysis these days?  
http://www.threatcode.com


If you are a SBSer

RE: [ActiveDir] FMSO roles split, patch question.

I completely disagree with you. I understand the thinking behind the move-roles-before-patch stance. I just don't buy into it. Test patch and be sure it doesn't kill things. Test your config changes and be sure it doesn't break things. Test, test and test more before you move into production.

Then deploy to production. IF, in spite of all your tests, "something" goes wrong with one DC holding a specific role (or - perish the thought - ALL your roles), it's no big deal. As long as you have other DCs available to assume the roles, the target DCwill not care how they got the roles (graceful transfer or inelegant seizure).

It's good to have a script that moves roles as you desire, but this does not fall into the realm of "best practice" in the scheme of things. Your energy should be invested in instituting a comprehensive patch/change management and testing operations practice rather than figuring out where to move roles to in case a patch eats your DC.

Sincerely,    _      (, /  |  /)   /) /)       /---| (/_  __   ___// _   //  _  ) /    |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /)     (/   Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon

From: joeSent: Thu 8/17/2006 9:31 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.
I completely concur with Jorge on his process. 

It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 

Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 

 joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen 
a "patch" kill a server.

Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.

But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.

Almeida Pinto, Jorge de wrote:
> the reason is that is a DC dies during the patching you do not have to
seize the rolesIMHO, I prefer transfering over seizing
>  
> Met vriendelijke groeten / Kind regards,
> Ing. Jorge de Almeida Pinto
> Senior Infrastructure Consultant
> MVP Windows Server - Directory Services
>  
> LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
> (   Tel : +31-(0)40-29.57.777
> (   Mobile : +31-(0)6-26.26.62.80
> *   E-mail : 
>
> 
>
> From: [EMAIL PROTECTED] on behalf of John Strongosky
> Sent: Thu 2006-08-17 16:55
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> I cornfused is this a standard practice as I thought you did not want to
move the FMSO roles back and forth. 
>  
> john
>
> 
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
Jorge de
> Sent: Thursday, August 17, 2006 4:33 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> in addition to that
> DC1 having FSMOset1 and DC2 having FSMOset2
> transfer FSMOset1 from DC1 to DC2
> apply patches to DC1

RE: [ActiveDir] FMSO roles split, patch question.

I am not into restoring from backup unless absolutely required. I like how
easy it is to rebuild and repromote. As I mentioned in the other post, I
consider DCs to be expendable like individual drives in a RAID Set.

Now if I was crazy enough to run a bunch of other services on a DC that were
specific to a given DC then I might be a little more likely to look at
restores but in the meanwhile I would have kicked my own butt for putting
myself in that position in the first place. You don't put extra services on
DCs for several reasons, not having to restore them is just a side effect.
Primarily you do it to reduce vectors against your security and stability.
In the SBS world I would be completely out of sorts with myself over their
working conditions. :) Hopefully all of the enterprise customers won't go
out of business though. ;)


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams
Sent: Thursday, August 17, 2006 12:58 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

Valid point.  But you should [try and] restore from the backup that ran the 
night before and that you verified successfully completed before you applied

the patch...   ;-)

If you have a document process that goes through the proper change control, 
then there shouldn't be any reason to do this.  The patches should be tested

in dev and pre-prod and then applied, only if there's a rollback option, and

that should be something like "uninstall patch; restore from last night's 
successful back if unable to boot and uninstall".


--Paul

- Original Message - 
From: "Almeida Pinto, Jorge de" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 17, 2006 4:02 PM
Subject: RE: [ActiveDir] FMSO roles split, patch question.


the reason is that is a DC dies during the patching you do not have to seize

the rolesIMHO, I prefer transfering over seizing

Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services

LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of John Strongosky
Sent: Thu 2006-08-17 16:55
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


I cornfused is this a standard practice as I thought you did not want to 
move the FMSO roles back and forth.

john



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, 
Jorge de
Sent: Thursday, August 17, 2006 4:33 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


in addition to that
DC1 having FSMOset1 and DC2 having FSMOset2
transfer FSMOset1 from DC1 to DC2
apply patches to DC1 and reboot and check everything (event logs DCdiag, 
etc)
if everything OK!
transfer FSMOset1 and FSMOset2 from DC2 to DC1
apply patches to DC2 and reboot and check everything (event logs DCdiag, 
etc)
if everything OK!
transfer FSMOset2 from DC1 to DC2
voila (that's french)...done! ;-)

jorge





From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
Sent: Wednesday, August 09, 2006 01:52
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.


It doesn't matter.



Sincerely,
   _
  (, /  |  /)   /) /)
/---| (/_  __   ___// _   //  _
) /|_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
   (/
Microsoft MVP - Directory Services
www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about 
Yesterday? -anon



From: John Strongosky
Sent: Tue 8/8/2006 4:49 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FMSO roles split, patch question.


We have our FMSO roles split between 2 dc's. They are Schema Master/Domain 
Tree Operator on 1 and on 2,  the roles PDC Emulator/Rid Pool/Intrastate on 
the other. After I apply the patches from Microsoft what is the beat 
practices for the boot order...or does it matter?

1. Remote DC/GC's first
2. no. 1
3. then no 2.


thanks






This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an 
intended recipient then please promptly delete this e-mail and any 
attachment and all copies and inform the sender. Thank you.


List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.a

RE: [ActiveDir] FMSO roles split, patch question.

Minutes to hours. Depends on what exactly is going on. If it was heavy
maintanence do it as far as you want in advance, if rolling through applying
patches move the role, patch the server, move the role back. Depending on
how many patches and the reboot times it could be less than 5 minutes with
two FSMO moves in that time frame. The environment will be fine.

The worst role to move is the PDC role and that is simply because it is a
target for various things but moving the PDC role in 2K is so much
incredibly nicer than it was in NT4 and I don't hesitate to move it now.
Under NT4 there were many times I would sit there and wonder, what is going
to screw up when I do this. And yes, many people will sit back and go huh,
there was no problem doing that in NT4... Trust me, in very large NT domains
(>60k users[1] and hundreds of WAN based BDCs) it could get tricky. More
than once I saw a PDC role transfer result in two hung servers that had to
be hard reset. 

Once you move the role, if you are worried, simply take a peek at the DNS
records to make sure the PDC record was updated and make sure the WINS 1B
record reflects the new PDC and everything is good. Most legacy functions
that need the PDC will ask for the 1B record and then hit the server listed
and ask, hey are you the PDC? If the response comes back as negative, the
machine will get the entire 1C record and send the request to every DC
listed in the 1C record (25 machines) and probably find it that way. If it
doesn't the call will fail and you will get, couldn't find the PDC or
couldn't find the domain. The one time I recall troubleshooting that for
someone they had moved the PDC role to a machine that wasn't properly
configured for WINS or it was actually incorrectly running the WINS Service
or something like that. It was a dee de dee move on the part of some admin
that caused the issue, not anything technical. 


  joe


[1] While there was a recommended limit of no more than 40k users in a
domain in NT4 I stumbled into an environment that people hadn't been paying
attention and had 3 domains over that limit, ~65k, ~85k and ~110k. It works,
you just burn a PS/2 Token Ring card every morning in an offering to the IT
gods... 


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky
Sent: Thursday, August 17, 2006 12:50 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.

Whets the time interval on moving these before you patch the DC's that the
roles were on.

john

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, August 17, 2006 9:32 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.

I completely concur with Jorge on his process. 

It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 

Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 

 joe


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen a
"patch" kill a server.

Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they
would find ahead of time if basic functionality of a DC would be nailed.

But if the server

RE: [ActiveDir] [OT] Longhorn Beta




I believe Longhorn/Vista is an invite only Connect 
program.  
 
 

--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of WATSON, 
BENSent: Thursday, August 17, 2006 1:46 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] [OT] Longhorn 
Beta


That was definitely the 
first place I checked, and unless I’m blind (which I’ve been accused of many 
times by the way), I don’t believe it’s an available option on the connect 
website to test.
 
I’ll probably end up 
just using my MSDN copy in our test environment to create a Longhorn 
DC.
 




From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Paul 
WilliamsSent: Thursday, August 
17, 2006 10:01 AMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] [OT] Longhorn 
Beta
 

http://connect.microsoft.com/

 

 

--Paul

  
  - Original Message - 
  
  
  From: WATSON, 
  BEN 
  
  To: ActiveDir@mail.activedir.org 
  
  
  Sent: Thursday, 
  August 17, 2006 4:35 PM
  
  Subject: 
  [ActiveDir] [OT] Longhorn Beta
  
   
  Outside of my MSDN account is 
  there a preferred way to obtain Longhorn Beta’s for 
  testing?
   
  ~Ben

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread Brian Desmond









Nah, even when you test stuff still can go wrong. It takes so
little time to just transfer the roles. I don’t backup/restore, I just
reimage/rebuild. DCs are expendable. Last big client I had, the forest roles
floated around the enterprise core sites, and the domain roles floated around
the sites they belonged in. Frankly I had no firm idea of exactly where they
were, just the general idea of where to find the role holders…netdom query fsmo
did the trick.

 



Thanks,

Brian Desmond

[EMAIL PROTECTED]

 

c - 312.731.3132



 







From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Deji Akomolafe
Sent: Thursday, August 17, 2006 12:53 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.





 





I completely disagree with you. I understand the thinking behind
the move-roles-before-patch stance. I just don't buy into it. Test patch and be
sure it doesn't kill things. Test your config changes and be sure it doesn't
break things. Test, test and test more before you move into production.





 





Then
deploy to production. IF, in spite of all your tests, "something"
goes wrong with one DC holding a specific role (or - perish the thought - ALL
your roles), it's no big deal. As long as you have other DCs available to
assume the roles, the target DCwill not care how they got the roles (graceful
transfer or inelegant seizure).





 





It's
good to have a script that moves roles as you desire, but this does not fall
into the realm of "best practice" in the scheme of things. Your
energy should be invested in instituting a comprehensive patch/change
management and testing operations practice rather than figuring out where to
move roles to in case a patch eats your DC.





 












Sincerely, 
  
_   

  (, /  | 
/)  
/) /)   
    /---| (/_  __   ___// _  
//  _ 
 ) /    |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/
/)  
  
(/   
Microsoft MVP - Directory Services
www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about Yesterday?
-anon









 







From: joe
Sent: Thu 8/17/2006 9:31 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.



I completely concur with Jorge on his process.  It takes a lot less hassle and a lot less feeling of concern to move a FSMOprior to an update of a machine than to have to seize the role laterregardless of the reason of it going down. Especially when you have a scriptthat applies the NTSUTIL commands to move the roles. A move of all roles ina properly scripted environment is a procedure that takes all of about 10-15seconds. A seize on the other hand isn't something you should just quicklythink about doing, you need to work out the consequences and make adetermination in most cases whether or not you will ever bring that DC backup as it stands now. It is, IMO, a no-brainer if you have multiple DCs as itis isn't any real workload or concern to do it. When I am doing production ops I *always* move roles prior to making machinespecific updates. I never assume a server is going to come back up after Isay restart or in fact even go down properly without hanging.  Now I understand the SBS thoughts behind it though... In the SBS world ifyou lost the DC, you have far greater issues than you lost a FSMO role forthe moment. In the world outside of SBS, most people look at DCs asexpendable. You set up 10 of them in front of you and 5 fell down you wouldbe like, crap, I will have to fix those at some point. You set up an SBS DCand it falls over there are skid marks where you were previously standing.   joe  --O'Reilly Active Directory Third Edition -http://www.joeware.net/win/ad3e.htm   -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPAaka Ebitz - SBS Rocks [MVP]Sent: Thursday, August 17, 2006 11:48 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] FMSO roles split, patch question. As a person who tests/patches a bunch of single DCs I've never seen a "patch" kill a server. Driver update may and has, yes.Impair functionality of the server, yes. But kill it completely?  Microsoft tests patches ahead of time and they would find ahead of time if basic functionality of a DC would be nailed. But if the server dies... it was probably on the emergency list prior to patching.  Rebooting the box first ensures that you find these 'hospital bound' servers. Almeida Pinto, Jorge de wrote:> the reason is that is a DC dies during the patching you do not have toseize the rolesIMHO, I prefer transfering over seizing>  > Met vriendelijke groeten / Kind regards,> Ing. Jorge de Almeida Pinto> Senior Infrastructure Consultant> MVP Windows Server - Directory Services>  > LogicaCMG Nederland B.V. (BU RTINC Eindhoven)> (   Tel : +31-(0)40-29.57.777> (   Mobile :

RE: [ActiveDir] FMSO roles split, patch question.




That is fine Deji, you can completely disagree as much you 
want, it wouldn't be the first time we haven't agreed. :)
 
BTW, I never said Best Practice, I said this is what I do 
and I agree with Jorge. But in the end, I don't care about best practices, I do 
what I think is right and the least likely to cause me issues balanced by my 
efficiency of doing things. 
 
You could test something to within an inch of its existence 
and something still go wrong in production, there is no way to guarantee no 
issues will occur, that is why we test in the first place. If it could be 
guaranteed, MSFT would have already done so. So you can put your faith in god 
all you want but it is prudent to row away from the rocks as 
well.
 
I am confused as to what disadvantage there is 
to moving roles? You seem to be saying since it isn't troublesome to seize 
them you shouldn't tranfer them. That is cracked.
 
Note that I don't say do this just for patching, any reboot 
or machine specific core change and I will move the roles. It could be something 
completely unrelated to a patch that caused a failure, especially in a reboot 
situation. It is such an innocuous thing to do that can save concern and work in 
the event of a failure. I think if it is easy to do up front, it seems outright 
stupid to not move the roles and remove all possibility of an issue around them. 
If I had a DC fail while doing maintenance work, I don't want to have to have 
made up issues for me to deal with around it, just get the DC working again. I 
can guarantee you several large companies that I have done work for would all 
question the process if I didn't do everything I could to limit possible issues 
up front. 
 
I would argue, and have in the past argued, that 
a seize is not as good as a tranfer regardless of your thoughts on the topic. If 
that weren't the case, it is probably likely there wouldn't be two methods in 
the first place. Even now there doesn't really need to be two methods, you could 
have one method for transfer and if that fails it does the seize but they 
specifically want you realizing you are seizing. Even if this weren't the case, 
I would STILL move the roles because it is simple and innocuous and 
fast.
 
In the end, you can do anything you want to to manage your 
environments as you see fit, but any environment I run will be handled as I 
indicated. I see it as such free insurance that is silly not to buy. 

 
Let me leave you with a scenario, feel free not to respond 
if you want.
 
You and I are working on our enterprise environments. We 
need to patch or do something else which will require a reboot. I go ahead 
and quickly move the roles and you just go forward in patching, I am slow that 
day so it takes 30 seconds instead of 15 seconds to move roles and then I 
am patching. You obviously hit reboot first, uh no, the reboot hangs up or the 
server doesn't reboot or doesn't even POST. 30 seconds later I see the same 
thing... Assuming we built out Domain Controller Architecture properly what 
happens next?
 
 
I go, well that sucks, I will have to fix that at some time 
and determine when I will make time for it and decide if I will troubleshoot and 
correct or just wipe and reload. 
 
You go, *&[EMAIL PROTECTED]. Do 
I fix this or do I seize the roles and you think about it while I am getting in 
my jeep and driving to meet friends or have lunch or dinner. (or 
alternately maybe some more junior admin makes the WRONG decision without you 
there..) Once you finally decide what direction you go, you then know what you 
can properly do. In the meanwhile, your decision may get pushed as users and 
admins start noticing things aren't as they should be. The GPO management tools 
are bitching about which machine they should talk to. Users changing passwords 
via tools using legacy API (yes they still exist even if clients don't) are all 
breaking. Password chaining isn't working for anyone that changed their 
passwords. Who knows what else is going on, you get to figure it out. I am 
drinking my second Labatt's not having to make any difficult decisions. 

 
All over a 15 second process handled by a batch file that 
took what maybe 30-60 minutes to write.
 
  joe
 
 
 

--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Deji 
AkomolafeSent: Thursday, August 17, 2006 1:53 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
split, patch question.


I completely disagree with 
you. I understand the thinking behind the move-roles-before-patch stance. I just 
don't buy into it. Test patch and be sure it doesn't kill things. Test your 
config changes and be sure it doesn't break things. Test, test and test more 
before you move into production.
 
Then deploy to production. IF, in spite of 
all your tests, "something" goes wrong with one DC holding a specific role (or - 
perish the thought - ALL your role

RE: [ActiveDir] FMSO roles split, patch question.




I always try to frame my responses around the requested info. In tis case, the OP wanted to know the folloing:
 
After I apply the patches from Microsoft what is the beat practices for the boot order...or does it matter?1. Remote DC/GC's first2. no. 13. then no 2.
The simple and logical answer is "it does not matter". The order of your patching and rebooting your DC is NOT depepndent on the roles they hold.
 
Everything else you've written in your response is all well and good. Nice to have, if I must say. I still stand by the original response. You do NOT have to put a lot of thoughts into playing chess with your roles just to figure out which one to reboot first. DCs are dispensable, even the role-holding ones - as long as there are others in the environment.
 


Sincerely,    _      (, /  |  /)   /) /)       /---| (/_  __   ___// _   //  _  ) /    |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /)     (/   Microsoft MVP - Directory Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon


From: joeSent: Thu 8/17/2006 12:25 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles split, patch question.

That is fine Deji, you can completely disagree as much you want, it wouldn't be the first time we haven't agreed. :)
 
BTW, I never said Best Practice, I said this is what I do and I agree with Jorge. But in the end, I don't care about best practices, I do what I think is right and the least likely to cause me issues balanced by my efficiency of doing things. 
 
You could test something to within an inch of its existence and something still go wrong in production, there is no way to guarantee no issues will occur, that is why we test in the first place. If it could be guaranteed, MSFT would have already done so. So you can put your faith in god all you want but it is prudent to row away from the rocks as well.
 
I am confused as to what disadvantage there is to moving roles? You seem to be saying since it isn't troublesome to seize them you shouldn't tranfer them. That is cracked.
 
Note that I don't say do this just for patching, any reboot or machine specific core change and I will move the roles. It could be something completely unrelated to a patch that caused a failure, especially in a reboot situation. It is such an innocuous thing to do that can save concern and work in the event of a failure. I think if it is easy to do up front, it seems outright stupid to not move the roles and remove all possibility of an issue around them. If I had a DC fail while doing maintenance work, I don't want to have to have made up issues for me to deal with around it, just get the DC working again. I can guarantee you several large companies that I have done work for would all question the process if I didn't do everything I could to limit possible issues up front. 
 
I would argue, and have in the past argued, that a seize is not as good as a tranfer regardless of your thoughts on the topic. If that weren't the case, it is probably likely there wouldn't be two methods in the first place. Even now there doesn't really need to be two methods, you could have one method for transfer and if that fails it does the seize but they specifically want you realizing you are seizing. Even if this weren't the case, I would STILL move the roles because it is simple and innocuous and fast.
 
In the end, you can do anything you want to to manage your environments as you see fit, but any environment I run will be handled as I indicated. I see it as such free insurance that is silly not to buy. 
 
Let me leave you with a scenario, feel free not to respond if you want.
 
You and I are working on our enterprise environments. We need to patch or do something else which will require a reboot. I go ahead and quickly move the roles and you just go forward in patching, I am slow that day so it takes 30 seconds instead of 15 seconds to move roles and then I am patching. You obviously hit reboot first, uh no, the reboot hangs up or the server doesn't reboot or doesn't even POST. 30 seconds later I see the same thing... Assuming we built out Domain Controller Architecture properly what happens next?
 
 
I go, well that sucks, I will have to fix that at some time and determine when I will make time for it and decide if I will troubleshoot and correct or just wipe and reload. 
 
You go, *&[EMAIL PROTECTED]. Do I fix this or do I seize the roles and you think about it while I am getting in my jeep and driving to meet friends or have lunch or dinner. (or alternately maybe some more junior admin makes the WRONG decision without you there..) Once you finally decide what direction you go, you then know what you can properly do. In the meanwhile, your decision may get pushed as users and admins start noticing things aren't as they should be. The GPO manage

RE: [ActiveDir] [OT] Longhorn Beta

true when invited you can activate it on the connect site and play around 
with it
 
Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services
 
LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : 



From: [EMAIL PROTECTED] on behalf of joe
Sent: Thu 2006-08-17 20:15
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Longhorn Beta


I believe Longhorn/Vista is an invite only Connect program.  
 
 
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN
Sent: Thursday, August 17, 2006 1:46 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OT] Longhorn Beta



That was definitely the first place I checked, and unless I'm blind (which I've 
been accused of many times by the way), I don't believe it's an available 
option on the connect website to test.

 

I'll probably end up just using my MSDN copy in our test environment to create 
a Longhorn DC.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams
Sent: Thursday, August 17, 2006 10:01 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] [OT] Longhorn Beta

 

http://connect.microsoft.com/

 

 

--Paul

- Original Message - 

From: WATSON, BEN   

To: ActiveDir@mail.activedir.org 

Sent: Thursday, August 17, 2006 4:35 PM

Subject: [ActiveDir] [OT] Longhorn Beta

 

Outside of my MSDN account is there a preferred way to obtain Longhorn 
Beta's for testing?

 

~Ben



This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.
<>

RE: [ActiveDir] FMSO roles split, patch question.

2006-08-17 Thread Gordon Pegue

What about us poor admins, who for a variety of reasons 
outside their control, don't have a "test" environment?
I'm just a little guy, supporting a small business that 
doesn't have kilobucks to spare for non-production 
equipment.

I sweat bullets every time MS issues updates and I spend a 
lot of time researching each and every one of them before I 
apply...

ThanksGordon PegueSystem AdministratorChavez Grieves 
Consulting EngineersAlbuquerque, NMwww.cg-engrs.com  

  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Deji 
  AkomolafeSent: Thursday, August 17, 2006 11:53 AMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] FMSO roles 
  split, patch question.

  I completely disagree with 
  you. I understand the thinking behind the move-roles-before-patch stance. I 
  just don't buy into it. Test patch and be sure it doesn't kill things. Test 
  your config changes and be sure it doesn't break things. Test, test and test 
  more before you move into production.

  Then deploy to production. IF, in spite 
  of all your tests, "something" goes wrong with one DC holding a specific role 
  (or - perish the thought - ALL your roles), it's no big deal. As long as you 
  have other DCs available to assume the roles, the target DCwill not care how 
  they got the roles (graceful transfer or inelegant seizure).

  It's good to have a script that moves 
  roles as you desire, but this does not fall into the realm of "best practice" 
  in the scheme of things. Your energy should be invested in instituting a 
  comprehensive patch/change management and testing operations practice rather 
  than figuring out where to move roles to in case a patch eats your 
  DC.

  Sincerely,    
  _    
    (, /  |  
  /)   
  /) /)       /---| 
  (/_  __   ___// _   //  _  ) 
  /    |_/(__(_) // 
  (_(_)(/_(_(_/(__(/_(_/ 
  /)  

  (/   Microsoft MVP - Directory 
  Serviceswww.akomolafe.com - we know IT-5.75, -3.23Do you now realize that Today is the Tomorrow you 
  were worried about Yesterday? 
  -anon

  From: joeSent: Thu 8/17/2006 9:31 
  AMTo: ActiveDir@mail.activedir.orgSubject: RE: 
  [ActiveDir] FMSO roles split, patch question.
  I completely concur with Jorge on his process. 

It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.

When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging. 

Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing. 

 joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FMSO roles split, patch question.

As a person who tests/patches a bunch of single DCs I've never seen 
a "patch" kill a server.

Driver update may and has, yes.
Impair functionality of the server, yes.

But kill it completely?  Microsoft tests patches ahead of time and they 
would find ahead of time if basic functionality of a DC would be nailed.

But if the server dies... it was probably on the emergency list prior to 
patching.  Rebooting the box first ensures that you find these 'hospital 
bound' servers.

Almeida Pinto, Jorge de wrote:
> the reason is that is a DC dies during the patching you do not have to
seize the rolesIMHO, I prefer transfering over seizing
>  
> Met vriendelijke groeten / Kind regards,
> Ing. Jorge de Almeida Pinto
> Senior Infrastructure Consultant
> MVP Windows Server - Directory Services
>  
> LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
> (   Tel

RE: [ActiveDir] FMSO roles split, patch question.