There is no way for MS to think of every eventuality and to support
every possibility that a customer (or even a large group of customers)
may want and/or desire.

At NT4 and before, if that was the case, you were pretty much SOL;
unless you could do some pretty heavy C-or-C++ coding.

Starting with Windows 2000, greatly improved with Windows Server 2003,
and [drool] revolutionally improved with Monad -- you could script
things yourself without having to be a rocket-scientist. 

I'll take a script, that I can review and correct if necessary, before a
wizard written by someone with SBS in mind. :-)

M

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley
Sent: Wednesday, November 30, 2005 10:31 PM
To: [email protected]
Subject: Re: [ActiveDir] FSMO role transfer...sorta wandering off into
Scripting

But why reinvent the wheel individually when we should be asking
Microsoft to either fix the wheel or build us a wheel in the first
place?  If it's a task that is repetitively done, has value, is used
over and over again, I'd rather trust a gui wizard/console/button that's
gone through beta testing by various testers that lays down an audit log
file than a home grown script [no offense guys] that I'd have to go get
interpreted.

Take the Security configuration wizard for example.. versus your own
home grown version of the same.  I'll take the SCW because I can see and
confirm the resulting XML file, the program has been through beta
testing process so in my brain I assign it a bit of lesser testing
resources.

For my space, I trust the gui way more than I do a script from a web
site that possibly wasn't built with SBS in mind.

But the gang that does Scripting drools over Monad.  So get ready for
Scripting on steriods.

http://www.microsoft.com/downloads/details.aspx?FamilyID=2ac59b30-5a44-4
782-b0b7-79fe2efd1280&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=8a3c71d1-18e5-4
9d7-952a-c55d694ecee3&displaylang=en

David Cliffe wrote:

>Well, I just think that most of the people in the command line and/or 
>scripting "camp" like to encourage others to learn to use them simply 
>because they feel it's to your benefit.  I don't think they really like

>to promote the "you're not a real admin..." sentiment.  Or at least I 
>hope not :-)  Right now in my org, I'm in the minority using the CLI.  
>I just prefer working that way and don't knock my colleagues for their 
>methods, but rather show them other ways to get at the info they need.
>
>CLI and scripting fosters your knowledge of what's happening in the 
>background, helps you learn the product and truly is a great way to 
>automate tasks!  (if not THE way)
>
>For the longest time I've been meaning to learn VBscript, but haven't 
>devoted enough time to go for it yet.  From what I've seen so far, it 
>scares me  :-P  but I still intend to give it a shot.  I've been 
>getting by with Perl and CMD shell for now (I came from a KSH/*nix
background).
>Have you seen some of the sample command shell scripts Dean has put 
>together?  Or the stuff that Alain Lissoir can do with WMI?  Wow!
>
>Anyway, this topic has drifted further now, but I'm going to resist the

>urge to change the subject line.  The last time I did that, we had a 
>little side bit just on the fact that the subject line changed! :-D
>
>-DaveC
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb
>Sent: Wednesday, November 30, 2005 5:18 PM
>To: [email protected]
>Subject: RE: [ActiveDir] FSMO role transfer
>
>Susan,
>
>"THANK YOU
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
>!!!!
>!!!!!!!!!!!"
>
>There are a >LOT< of people on this list that do not believe that real 
>Admins use the GUI.  Some believe that you're not a real Admin if you 
>do.  I do.  I have to.  I can't allocate time to learn scripting right 
>now because I'm overworked as is.  I'll just leave it at that.
>
>RH
>______________________________________________
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] Behalf Of Susan Bradley, 
>CPA aka Ebitz - SBS Rocks [MVP]
>Sent: Wednesday, November 30, 2005 4:09 PM
>To: [email protected]
>Subject: Re: [ActiveDir] FSMO role transfer
>
>
><stupid question alert>
>
>If the task is that trivial
>If the benefit is so great
>Why isn't it part of the AD snap ins as a one button task?
>
><sincerely, who needs scripting when you can ask for a gui/wizard or 
>button instead>
>
>David Adner wrote:
>  
>
>>I'm not debating the effort it takes to make the change.  I'm saying I
>>    
>>
>don't
>  
>
>>see the point in devoting whatever amount of effort it takes for 
>>something that's going to provide benefit only, IMO, an extremely rare
>>    
>>
>
>  
>
>>case.  And if that case happened, the corrective action is also a 
>>trivial process.  And again, I'm not saying I don't see your point; I
>>    
>>
>just don't agree with it.
>  
>
>>    
>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED] On Behalf Of Bahta 
>>>Nathaniel V Contractor NASIC/SCNA
>>>Sent: Wednesday, November 30, 2005 12:32 PM
>>>To: [email protected]
>>>Subject: RE: [ActiveDir] FSMO role transfer
>>>
>>>That process is trivial in itself.  It does not take much to transfer
>>>      
>>>
>
>  
>
>>>the roles before you conduct maintenance on a server.  Why not do it?
>>>      
>>>
>
>  
>
>>>It will save you cleaning up metadata after you seize a role of a 
>>>failed operations master.  Sounds like a stitch in nine saves time 
>>>concept to me.  I do not intend on taking every proactive measure 
>>>either, but when it comes to the small and quickly implemented 
>>>measures that could save plenty of time, I try to utilize all of them
>>>      
>>>
>
>  
>
>>>available.
>>>
>>>Is that agreeable?
>>>
>>>Nathaniel Vincent Bahta
>>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED] On Behalf Of David Adner
>>>Sent: Wednesday, November 30, 2005 1:24 PM
>>>To: [email protected]
>>>Subject: RE: [ActiveDir] FSMO role transfer
>>>
>>>Any proper maintenance plan has a backout plan and a recovery plan, 
>>>so I am preparing for the possibility of an unexpected problem.  If 
>>>I'm pulled into a dark room because something goes wrong then I 
>>>should feel confident I'll leave that room with my hide mostly 
>>>intact; it may be slightly singed, but I can live with that.  If 
>>>management isn't the reasonable type then that's a different issue.
>>>
>>>If your philosophy is to take every proactive measure ahead of time 
>>>possible, then that's fine.  I just don't see the point with regards 
>>>to FSMO roles when the recovery action is a relatively trivial 
>>>process.  This is obviously a matter of personal preference so I'm 
>>>not trying to convince others to change.  I just found the concept 
>>>unusual so I thought I'd share.
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: [EMAIL PROTECTED]
>>>>[mailto:[EMAIL PROTECTED] On Behalf Of 
>>>>[EMAIL PROTECTED]
>>>>Sent: Wednesday, November 30, 2005 10:16 AM
>>>>To: [email protected]
>>>>Subject: RE: [ActiveDir] FSMO role transfer
>>>>
>>>>I would rather, as stated earlier, assess the risk and then act 
>>>>appropriately. The original poster never defined 'maintenance' in 
>>>>detail.
>>>>
>>>>The original post did state that the box would be down for ~2 hours 
>>>>for maintenance. This is clearly more than a patch and a
>>>>
>>>>        
>>>>
>>>reboot. We've
>>>
>>>      
>>>
>>>>been over that scenario and concluded that it carries a lesser risk.
>>>>
>>>>As joe said, if the maintenance all goes badly wrong, do
>>>>
>>>>        
>>>>
>>>you want to
>>>
>>>      
>>>
>>>>be pulled into a dark room and questioned as to why you did not 
>>>>prepare for that eventuality?
>>>>
>>>>
>>>>neil
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: [EMAIL PROTECTED]
>>>>[mailto:[EMAIL PROTECTED] On Behalf Of Susan 
>>>>Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>>>Sent: 30 November 2005 15:29
>>>>To: [email protected]
>>>>Subject: Re: [ActiveDir] FSMO role transfer
>>>>
>>>>Okay define maintenance please?
>>>>
>>>>Patching?
>>>>Service Pack?
>>>>Applying QFEs?
>>>>Performance tuning?
>>>>What?
>>>>
>>>>Is there a level of maintenance that would cause you to move FSMO's 
>>>>and not?
>>>>
>>>>Like for example, if I'm patching, I've tested the patch, I'm 
>>>>reasonably expecting a favorable outcome otherwise I wouldn't be 
>>>>deploying, I have a backup.
>>>>
>>>>[EMAIL PROTECTED] wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>I think we've missed the essence of the original post :)
>>>>>
>>>>>          
>>>>>
>>>>The DCs are
>>>>
>>>>        
>>>>
>>>>>not just being rebooted, they are being 'maintained' and
>>>>>
>>>>>          
>>>>>
>>>>will be down
>>>>
>>>>        
>>>>
>>>>>for ~ 2 hours. That means to me, that either a s/w or h/w
>>>>>
>>>>>          
>>>>>
>>>change is
>>>
>>>      
>>>
>>>>>going to occur which could go horribly wrong. Faced with this 
>>>>>situation, I would definitely transfer the roles.
>>>>>If the DC were merely being rebooted and nothing else is
>>>>>
>>>>>          
>>>>>
>>>>scheduled to
>>>>
>>>>        
>>>>
>>>>>occur, I would not transfer roles.
>>>>>The above 2 scenarios are very different - if one were to
>>>>>
>>>>>          
>>>>>
>>>perform a
>>>
>>>      
>>>
>>>>>risk analysis the actions taken to mitigate those risks would be 
>>>>>suitably different.
>>>>>neil
>>>>>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>-
>>>
>>>      
>>>
>>>>>--
>>>>>*From:* [EMAIL PROTECTED]
>>>>>[mailto:[EMAIL PROTECTED] *On Behalf Of
>>>>>
>>>>>          
>>>>>
>>>>*David Adner
>>>>
>>>>        
>>>>
>>>>>*Sent:* 29 November 2005 23:26
>>>>>*To:* [email protected]
>>>>>*Subject:* RE: [ActiveDir] FSMO role transfer
>>>>>
>>>>>I would only agree if you told me your DC's regularly
>>>>>
>>>>>          
>>>>>
>>>fail to come
>>>
>>>      
>>>
>>>>>back after a reboot. And if you did tell me that I'd have to say 
>>>>>you're doing something wrong.
>>>>>I suppose I don't consider rebooting a DC to be quite the
>>>>>
>>>>>          
>>>>>
>>>dangerous
>>>
>>>      
>>>
>>>>>act as others do. To what degree is this taken? If it holds
>>>>>
>>>>>          
>>>>>
>>>>a standard
>>>>
>>>>
>>>>        
>>>>
>>>>>Primary zone do you transfer that role, too? If it's the
>>>>>
>>>>>          
>>>>>
>>>>PDCE of the
>>>>
>>>>        
>>>>
>>>>>forest root domain and you transfer the role, do you also
>>>>>
>>>>>          
>>>>>
>>>>reconfigure
>>>>
>>>>        
>>>>
>>>>>the new PDCE to manually synchronize time from an authoritative 
>>>>>source? I mean, if we're going to work under the
>>>>>
>>>>>          
>>>>>
>>>assumption that a
>>>
>>>      
>>>
>>>>>reboot is a regularly catastrophic causing event then
>>>>>
>>>>>          
>>>>>
>>>it's probably
>>>
>>>      
>>>
>>>>>time to switch OS's.
>>>>>Is it possible something unexpectedly horrible can happen
>>>>>
>>>>>          
>>>>>
>>>>as part of a
>>>>
>>>>
>>>>        
>>>>
>>>>>reboot? Sure. But it better be the exception. And with
>>>>>
>>>>>          
>>>>>
>>>>regards to FSMO
>>>>
>>>>
>>>>        
>>>>
>>>>>roles, which, barring some specific technical requirement they be 
>>>>>readily available, the temporary outage of them is typically a 
>>>>>transparent event and shouldn't require added
>>>>>
>>>>>          
>>>>>
>>>>administrative overhead
>>>>
>>>>        
>>>>
>>>>>in transferring them back and forth. Accepting that a
>>>>>
>>>>>          
>>>>>
>>>catastrophic
>>>
>>>      
>>>
>>>>>event is an exception, then you follow your documented and tested 
>>>>>activities to recover from that exception; ie: you seize
>>>>>
>>>>>          
>>>>>
>>>the roles,
>>>
>>>      
>>>
>>>>>restore from backup, etc.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>--------------------------------------------------------------
>>>>----------
>>>>
>>>>        
>>>>
>>>>>    *From:* [EMAIL PROTECTED]
>>>>>    [mailto:[EMAIL PROTECTED] *On
>>>>>
>>>>>          
>>>>>
>>>Behalf Of *Rich
>>>
>>>      
>>>
>>>>>    Milburn
>>>>>    *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>>    *To:* [email protected]
>>>>>    *Subject:* RE: [ActiveDir] FSMO role transfer
>>>>>
>>>>>    Yeah but having "seize the FSMOs instead of moving
>>>>>
>>>>>          
>>>>>
>>>them" as your
>>>
>>>      
>>>
>>>>>    fallback plan is like making sure you have a current backup in
>>>>>    case "yanking the power cord instead of Start > Shutdown >
>>>>>    Restart" causes file system corruption J
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>//------------------------------------------------------------
>>>>----------
>>>>-///
>>>>
>>>>        
>>>>
>>>>>    ///Rich Milburn///
>>>>>    ///MCSE, Microsoft MVP - Directory Services///
>>>>>    Sr Network Analyst, Field Platform Development
>>>>>    Applebee's International, Inc.//
>>>>>    //4551 W. 107th St//
>>>>>    //Overland Park//, KS 66207//
>>>>>    //913-967-2819//
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>//------------------------------------------------------------
>>>>----------
>>>>//
>>>>
>>>>        
>>>>
>>>>>    ///"I love the smell of red herrings in the morning" -
>>>>>
>>>>>          
>>>>>
>>>>anonymous//
>>>>
>>>>        
>>>>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>-
>>>
>>>      
>>>
>>>>>--
>>>>>
>>>>>    *From:* [EMAIL PROTECTED]
>>>>>    [mailto:[EMAIL PROTECTED] *On Behalf Of
>>>>>    [EMAIL PROTECTED]
>>>>>    *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>>    *To:* [email protected]
>>>>>    *Subject:* Re: [ActiveDir] FSMO role transfer
>>>>>
>>>>>    If something went wrong you could still seize the FSMO
>>>>>
>>>>>          
>>>>>
>>>>roles as an
>>>>
>>>>        
>>>>
>>>>>    option rather than doing a transfer. Of course the
>>>>>
>>>>>          
>>>>>
>>>>procedures for
>>>>
>>>>        
>>>>
>>>>>    all of these for the 5 FSMOs should be documented just in case
>>>>>    needed..
>>>>>
>>>>>    Chuck
>>>>>
>>>>>    /
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>--------------------------------------------------------------
>>>>----------
>>>>
>>>>        
>>>>
>>>>>    *-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY
>>>>>
>>>>>          
>>>>>
>>>>NOTICE-------*
>>>>
>>>>        
>>>>
>>>>>    PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this
>>>>>    message or any attachments. This information is strictly
>>>>>    confidential and may be subject to attorney-client
>>>>>
>>>>>          
>>>>>
>>>>privilege. This
>>>>
>>>>        
>>>>
>>>>>    message is intended only for the use of the named
>>>>>
>>>>>          
>>>>>
>>>addressee. If
>>>
>>>      
>>>
>>>>>    you are not the intended recipient of this message,
>>>>>
>>>>>          
>>>>>
>>>unauthorized
>>>
>>>      
>>>
>>>>>    forwarding, printing, copying, distribution, or using such
>>>>>    information is strictly prohibited and may be unlawful. If you
>>>>>    have received this in error, you should kindly notify
>>>>>
>>>>>          
>>>>>
>>>the sender
>>>
>>>      
>>>
>>>>>    by reply e-mail and immediately destroy this message.
>>>>>
>>>>>          
>>>>>
>>>>Unauthorized
>>>>
>>>>        
>>>>
>>>>>    interception of this e-mail is a violation of federal criminal
>>>>>    law. Applebee's International, Inc. reserves the right
>>>>>
>>>>>          
>>>>>
>>>>to monitor
>>>>
>>>>        
>>>>
>>>>>    and review the content of all messages sent to and from this
>>>>>    e-mail address. Messages sent to or from this e-mail
>>>>>
>>>>>          
>>>>>
>>>address may
>>>
>>>      
>>>
>>>>>    be stored on the Applebee's International, Inc.
>>>>>
>>>>>          
>>>>>
>>>e-mail system./
>>>
>>>      
>>>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>-
>>>
>>>      
>>>
>>>>>--
>>>>>
>>>>>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.
>>>>>
>>>>>          
>>>>>
>>>>List info   : http://www.activedir.org/List.aspx
>>>>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>>>>List archive:
>>>>http://www.mail-archive.com/activedir%40mail.activedir.org/
>>>>
>>>>
>>>>
>>>>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.
>>>>
>>>>List info   : http://www.activedir.org/List.aspx
>>>>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>>>>List archive:
>>>>http://www.mail-archive.com/activedir%40mail.activedir.org/
>>>>
>>>>        
>>>>
>>>List info   : http://www.activedir.org/List.aspx
>>>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>>>List archive:
>>>http://www.mail-archive.com/activedir%40mail.activedir.org/
>>>List info   : http://www.activedir.org/List.aspx
>>>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>>>List archive:
>>>http://www.mail-archive.com/activedir%40mail.activedir.org/
>>>
>>>      
>>>
>>List info   : http://www.activedir.org/List.aspx
>>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>>List archive: 
>>http://www.mail-archive.com/activedir%40mail.activedir.org/
>>
>>
>>    
>>
>
>--
>Letting your vendors set your risk analysis these days?
>http://www.threatcode.com
>
>List info   : http://www.activedir.org/List.aspx
>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>List archive:
>http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>
>
>List info   : http://www.activedir.org/List.aspx
>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>List archive:
>http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>
>To find out more about Reuters visit www.about.reuters.com
>
>Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
>
>List info   : http://www.activedir.org/List.aspx
>List FAQ    : http://www.activedir.org/ListFAQ.aspx
>List archive: 
>http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>  
>
List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to