----- Original Message -----
Sent: Tuesday, August 08, 2006 4:37
PM
Subject: RE: [ActiveDir] Moving Sysvol
.
All fair points, Paul - I guess I'd view these concerns
in a different way:
- Use a GPO management tool to abstract away native
GPO rights
- If admins cannot be trusted not to fill SYSVOL
with sh** then don't give them any rights in SYSVOL [similar to above
point]
- If SYSVOL has its own partition, you still have
the potential for adminA to fill the disk with cr** and thus hinder the
legitimate efforts of adminB to make changes to a GPO. Granted, this 'DOS'
only affects SYSVOL, but then if GPO is broken then you're in big trouble
anyway :)
- Granted a separate disk for logs
*is* overkill. Consider using that partition / disk in other ways (GPO
backups; system state backups, build source files etc
etc).
my 2 penneth,
neil
I believe the school of thought here is
that the person has write access to the same volume as the DIT, which means
he/ she can easily perform DOS attacks, etc. by filling up the disk.
I agree it's unlikely, but there you
go. Take the [real] examples of where people with write access to SYSVOL
have decided to replicate ghost images, etc. which not only trashes FRS, but
fills the disk so that only the 20MB reserve files are left (which can easily
be used up with dodgy custom synchronisation scripts that don't know what an
USN is [past experience showing?] ;-)
I don't believe the recommendations for
Logs and DIT go either. Yes, the logs are predominently write, while
most of the DIT usage is read, but the logs are circular. Why waste a
mirrored set for < 100 MB of disk even if disk is cheap? Plus, as
already stated in the same argument, most of the activity is read, so is there
really performance to be gained by having nano-second better response times on
the file writes? Other than implementation or re-provisioning or
restoration, I can't see the need to separate the logs.
I'm involved with a design at the moment
that has a 30+ GB DIT (~320,000 users at the moment) and I'm using my earlier
recommendations for the disks for DCs. We're arguing over whether RAID10
or RAID5 for the logical disk(s) that conatin the non-OS volumes should be
used, but there's not much difference there on a 4 - 6 disk set -the argument
is political to do with different standards for the management people.
But then, the SYSVOL volume is also a scratch area for administrators.
The DIT and OS volumes are very much off limits, and secured
thus.
--Paul
----- Original Message -----
Sent: Tuesday, August 08, 2006 3:58
PM
Subject: 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.
... 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
Yes, you can relocate the
SYSVOL. It's just a little more involved (couple of extra steps, not
difficult) than moving the DIT. See:
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 -----
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
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.
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.