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 50000000
CreateBogusFile2_100MB.cmd --> FSUTIL FILE CREATENEW E:\VMs\FakeFile2.bogus 100000000
CreateBogusFile3_200MB.cmd --> FSUTIL FILE CREATENEW E:\VMs\FakeFile3.bogus 200000000
 
For your DIT/SYSVOL volumes you can so something like
FSUTIL FILE CREATENEW <DRIVE>:\<PATH>\FakeFile.bogus 1000000000 (= 1 GB)
the numeric value is specified in KBs
 
jorge


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia
Sent: Tuesday, August 08, 2006 16:58
To: [email protected]
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.
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 6:58 AM
To: [email protected]
Subject: 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 Williams
Sent: 08 August 2006 13:35
To: [email protected]
Subject: 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:
 
 
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
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.


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.

Reply via email to