RE: [ActiveDir] NTDS.DIT Size
Yes, the dit is small for 250K users. It is really justused asan LDAP user store,and we only care about maybe 30 attributes. Our LSASS process does indeed get to about 1.3 gb every now and then, so maybe its getting close to time to use the /3GB switch, until we can get some new x64 hardware to throw at it. Can 32 and 64 bit ADs comingle? Thanks! Josh Date: Fri, 30 Jun 2006 00:44:46 -0700 From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] NTDS.DIT Size Someonesaidthis: Whateverneedstobeloadedshouldperformbetterwhensmaller. Isuspectthisisnottrue,oratleastnotverysignificant.OLD(OnLine Defrag)cinchesuptheDBsothefewestpagesareusedfordataand whitespaceisconsolidatedtowholepages,andsowhilebackuptimewould belonger/takeupmorespace,fromacachingperspectiveitshouldn't performanybetter. Cheers, -BrettSh[msft] OnFri,30Jun2006,BrianDesmondwrote: Soundslikehe'sprobablyjustnotpopulatingmanyattributes.I'vegot doublethatDITsizeataclientwithhalfthenumberofuserseasily. I'vealsoneverhadareasontodefragaditwhenIcanjustdcpromo down/upifIthinkitwillfixadatabaseissue.Thanks, BrianDesmond [EMAIL PROTECTED]c-312.731.3132From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]OnBehalfOfGrillenmeier, Guido Sent:Thursday,June29,20066:53PM To:ActiveDir@mail.activedir.org Subject:RE:[ActiveDir]NTDS.DITSize1.7GBfor250.000usersisprettysmallalready-Iguessyoudon'tuse Exchangeformessagingoruseextremelyfewattributesofyourobjects inAD.WiththestepsoutlinedbyUlfyoushouldgetafairideaonhow muchwhitespaceyoucurrentlyhave,however,youshouldn'texpectto havemuchifyourADisgrowingatafairlyconstantrate.Thedatabase growsfairlylinearandwhitespaceisbeingusedautomaticallybenew data.Asyou'retalkingaboutmovingto64-bit,Iguessyou'realreadyusing Win2003.On32-bitWindows2003DCswithout/3GBswitch,theLSASS processcanconsume(cache)uptoabout1.5GB,with/3GBit'saround 2.6GB./3GBissupportedonbothStandardandEnterpriseEditionwith respecttoDCs.Sotheoreticallyyou'rewellinthelimitsofthe32-bitOS,aslongas youhaveatleast4GBinyourDCsandareusingthe/3GBswitch. However,the/3GBswitchreducesthevitualmemoryforthekerneldown to1GB,withcanbealimitingfactorinothersituations-usuallynot onaDC(ifit'snotalsohostingmanyotherservices).Butthe64-bitDCswon'tcostyouonepennyextra:almostallserverHW forthepast12monthshasbeenx64capableandthe64-bitWin2003 versionhasthesamelicensingcostsasthe32-bitversion.Soyoumight aswellgoforitandhaveevenmoreroomforgrowth.Mindyou,with yourcurrentDITsizeyoushouldnotexpectmuchperformancedifference foryourAD(unlessyou'rereplacingoldserverHWwithnewHWatthe sametime...). /Guido From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]OnBehalfOfUlfB. Simon-Weidner Sent:Donnerstag,29.Juni200623:47 To:ActiveDir@mail.activedir.org Subject:RE:[ActiveDir]NTDS.DITSize HelloJoshua,I'dlookatthewhitespacetodeterminewhentoofflinedefragaDC.You canenabletheassociatedeventwhichwilltellyoutheamountof whitespacebysettingtheregistrykey HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\6Garbage Collectionto1insteadof0(whichisthedefault).Regkeymightbe likely-justtypeditfromhard. Thiswillgiveyouaneventeverytimewhengarbagecollectionruns (every12hrs)andtellyoutheamountofwhitespaceintheDB.Whateverneedstobeloadedshouldperformbetterwhensmaller.I'veheardthataDConx64willperformbetterthanon32-bit,since it'sverylikelyyoualreadyhavesomeofthenewerserverswithx64I'd justgiveitatryforoneDCyourself.Gruesse-Sincerely, UlfB.Simon-Weidner ProfilePublications: http://mvp.support.microsoft.com/profile=""> C811D BLOCKED::http://mvp.support.microsoft.com/profile=""> 89-F2F1214C811D Weblog:http://msmvps.org/UlfBSimonWeidner BLOCKED::http://msmvps.org/UlfBSimonWeidner Website:http://www.windowsserverfaq.org BLOCKED::http://www.windowsserverfaq.org/ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]OnBehalfOfJoshuaCoffman Sent:Thursday,June29,200610:59PM To:ActiveDir@mail.activedir.org Subject:[ActiveDir]NTDS.DITSizeOurAD(NTDS.dit)isat1.7GB(approx.250,000users). Shouldanofflinedefragbeperformedataregularinterval? SomearticlesIreadonlysayitisonlyworthwhileifyouarerunning lowonspace.WehaveplentyofdrivespaceandRAM. AtwhatpointshouldtheADbemovedto64bit? Thanks, Josh Listinfo:http://www.activedir.org/List.aspx ListFAQ:http://www.activedir.org/ListFAQ.aspx Listarchive:http://www.activedir.org/ml/threads.aspx
[ActiveDir] NTDS.DIT Size
Our AD (NTDS.dit) is at 1.7GB (approx. 250,000 users). Should an offline defrag be performed at a regular interval? Some articles I read only say it is only worthwhile if you are running low on space.We have plenty of drive space and RAM. At what point should the AD be moved to 64 bit? Thanks, Josh
[ActiveDir] Deny permissions in AD
I have an Active Directory 2003 domain that is used only as an LDAP User store for a 3rd party Identity Management Application. There are no workstations or servers in the domain, other than the DCs themselves. We are trying to lock down the domain, so that an ordinary user cannot read other user's attributes. For some specialattributes, we have implemented the 2K3 SP1 "Confidential Attribute" function, and it is working well. However, over the weekend, another administrator decided to try something that has me a little perplexed. Here is what the Admin did: Put a DENY ACEfor the "Domain Users" groupfor"Read All Properties" (in advanced security settings) on an OU containing a lot of users. Now, your average user account cannot read attributes, which is good. Domain Admins and Administrators can read the attributesof users in the OU,which is also good. However, I am wondering, whydoes thiswork this way? Shouldn't the DENYACE override all other permissions, including those inherited for domain Admins, which I believe is a member of the domain users group by default. Also, an additional group was created which allows read/write access to a singleuser attribute in the same OU. A non-administrative account, when added to this group,can read andwrite to the attribute, even though there is a deny on readall properties. Can anyone tell me why this is working this way? It is contrary towhat I thought Iknew about Deny ACEs. Thanks, Josh
RE: [ActiveDir] Deny permissions in AD
I think you are correct. I started lookinginto this immediately after posting. Looks like domain admins, Self, and account operators have hard-coded rights to the object. This would be applied before the inherited deny ACE. Thanks! JoshJoshuaM.Coffman[EMAIL PROTECTED]Cell:(970)402-3457 Subject: RE: [ActiveDir] Deny permissions in ADDate: Mon, 26 Jun 2006 13:50:13 -0400From: [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org Probably order of inheritance… 1. Noninherited Deny entries. 2. Noninherited Allow entries. 3. Inherited Deny entries. 4. Inherited Allow entries. :m:dsm:cci:mvp| marcusoh.blogspot.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Monday, June 26, 2006 1:44 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Deny permissions in AD I have an Active Directory 2003 domain that is used only as an LDAP User store for a 3rd party Identity Management Application.There are no workstations or servers in the domain, other than the DCs themselves.We are trying to lock down the domain, so that an ordinary user cannot read other user's attributes. For some specialattributes, we have implemented the 2K3 SP1 "Confidential Attribute" function, and it is working well.However, over the weekend, another administrator decided to try something that has me a little perplexed.Here is what the Admin did:Put a DENY ACEfor the "Domain Users" groupfor"Read All Properties" (in advanced security settings) on an OU containing a lot of users.Now, your average user account cannot read attributes, which is good. Domain Admins and Administrators can read the attributesof users in the OU,which is also good.However, I am wondering, whydoes thiswork this way? Shouldn't the DENYACE override all other permissions, including those inherited for domain Admins, which I believe is a member of the domain users group by default. Also, an additional group was created which allows read/write access to a singleuser attribute in the same OU. A non-administrative account, when added to this group,can read andwrite to the attribute, even though there is a deny on readall properties.Can anyone tell me why this is working this way? It is contrary towhat I thought Iknew about Deny ACEs.Thanks,Josh
RE: Re: [ActiveDir] Errors During Authoritative Restore
Thanks again for your help. I appreciate your feedback and expertise on the subject. Youare correct, this is a test of a bare-metal restore of the entire domain, where I bring in tapes from offsite and restore a single DC to a completely disconnected machine (on identical hardware). In this worst-case scenario, the plan was to restore asingle DC, perform metadata cleanup, and rebuild and dcpromo new replicas. I was under the impression that in order to restore the entire database from scratch, you had to mark the SYSVOL as primary, and perform an authoritative restore: restore database. Are you saying you just restore from tape, mark SYSVOL as primary, skip the auth restore commands in NTDSUTIL, and just perform the metadata cleanup functions, clean DNS, etc. and you are good to go? If this is correct, it would be a much cleaner/faster process, because we wouldn't have to be updating USNs on a half-million objects. It makes sense that it would not have to be authoritative, if all replica DC's were going to be new, but I(probably mistakenly)thought that the authoritative restore was a required step. Thanks!Josh Subject: RE: Re: [ActiveDir] Errors During Authoritative RestoreDate: Wed, 21 Jun 2006 08:48:25 +0100From: [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org glad Brett picked up on analysing the different errors you were getting - I've not seen these before. curious to hear what type of issue you aretesting to recover from? From what you write, I gather you are testing to restore your production domain to another (hopefully physically separated) test-system. I.e. you are testing a full recovery of your ADdomain or forest- is this correct? If so, authorititative restore of the AD DB is not the right approach anyways. The restore database option gives the false impression of doing a full recovery of AD - it bears more risks than value and likely this is why it was removed from Longhorn. In a distributed multi-master database such as AD, auth. restoring the partition of one DC will never completely overwrite the same partition of the other DCs: although you might be lucky and think you have fully recovered, any additional objects or new attributes added to existing objects in the respective AD partition after you performed the backup will replicate back to the restored DC. The correct way to fully restore AD is to restore only a single instance of the DB (i.e. a single DC) and re-build / re-promote all the other DCs. Instead of performing an auth. restore of the DB, you'd just restore it non-authoritatively anddo a metadata cleanup of all the otherDCs on the restored DC to ensure it is the only one representing your domain (you would mark SysVol as primary during the restore process). There are a few more steps to perform to ensure that the recovered DC doesn't replicate any data from other existing DCs in your environment - all of these are described in the (fairly old) AD Forest Recovery Whitepaper which pretty much also applies for full recovery of a single domain: http://www.microsoft.com/downloads/details.aspx?displaylang=enFamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE It's a little more complex in a multi-domain environment as you also have to take care of the partitions of your domain on GCs in other domains - if you're goal is to also fully restore the config partition, you're talking about a full forest restore anyways (which would roughtly use the same approach - restoring a single DC of every domain - then re-promoting all other DCs). Although LH backup and recovery procedures are not fully finalized yet, for full AD recovery the process would still roughly be the same asdescribed above(mind you there are big changes to the built-in backup-tool - and recovery of a DC to different HW should now also be a valid option). The main change with LH that will strongly influence time and risk for a domain/forest level restore is the fact that you will not have as many writeable DCs in your environment. Even if you are strongly distributed geographically, the goal will be to only host writeable DCs in your datacenters and make all the other DCs in your environment read-only. As the name implies, the Read-Only DCs (RODC) do not allow any originating writes on them and will never replicate anything back to a writeable DC - this way there is less work involved to ensure a consistent status of AD during the recovery. Not saying you won't also have to re-promote the RODCs, but you certainly have less writable DCs to worry about and can possible leave the RODCs running during the recovery process (we'll have to see about this).I have good hopes that this will increase the overall recovery-speed of AD inlarge distributed deployments. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua CoffmanSent: Dienstag, 20. Juni 2006 21:33To: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] Errors During Authoritative Restore Thanks Brett,I appreciate your assistance
[ActiveDir] Errors During Authoritative Restore
I have a few questions foryou AD gurus out there! :) I just ran through a Disaster Recovery test of two of our ADs and I have a few questions which have come up as a result of the test. Configuration Notes: These boxes are Windows 2003, SP1. The domains wereoriginally Windows 2000 domains. The followingerrors pop up on one of the domain controllers during the restore. "Could not display the attribute type for the object with DNT 831424.Error: failed to get dn of dnt 831424" This occurs many times throughout the restore. NOTE: This is during a complete restore,e.g."authoritative restore: restore database" I also see a few of these. "There was an error parsing the GUID from the file on line: 1981" (Not to many of these, maybe four or five) Additionally, with SP1,LDIF files are created to restore back-links. The file that restores the user/group back-links imports successfully. The file that restores the configuration back-links fails. (sorry, I do not have the error handy) The authoritative restore says it completed successfully, and after I go through metadata cleanup and FSMO seizure, the box starts up without any errors, and AD throws no errors on startup. I was wondering if anyone can tell me what these errors mean? What are their ramifications? How can the errors be resolved. Thanks, Josh
RE: Re: [ActiveDir] Errors During Authoritative Restore
Thanks Brett, I appreciate your assistance on this. Yes, there are tons of schema mods. In the domain throwing the majority of the errors, these mods were performed using an LDIF file, during the installation of a 3rd partyIdentity Management Application. I do not know if therehave beenLDAP naming attributes added or not. If you can send a query to verify, I would be happy to run it. I knew that Restore Database is the "last resort" method, but that is what we wanted to test. We do have multiple DCs replicating across multiple geographic sites, so this scenario is unlikely, unless there were some sort of catastrophic corruption that took place. In the future, if "restore database" is unavailable, what will be used in its place if you need to do a bare metal authoritative restore of the entire AD? It will take a while to run the tools you requested against the AD, because it is a production system. I cannot run them directlyin the PROD environment, so I would have to pull a mirrored drive from the prod DC, and pop it into an offline server. This could take a while for the required approvals. Thanks again for your help! Josh Date: Tue, 20 Jun 2006 10:09:58 -0700 From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Errors During Authoritative Restore Doyouhaveanyschemaextensionsapplied?Doyouknowifthoseschemas addedanyLDAPnamingattributes?Ifthe2ndquestiondoesn'tmakesense toyou,I'llfigureoutawayyoucanquerythis,andsendittous. Aside,itisgenerallynotrecommendedtorun"restoredatabase".Infact thiscommandwasremovedfromLonghorn. Ifyoudecidetoretrythatscenarioagain,Icansuggestsome intermediatestepsthatwouldbegoodtoknow.i.e. 1.Beforerunningauthrestore,beinterestingtoknowtheresultsofan esentutl/kntds.dit(checksumthedatabase). 2.Afterauthrestore,itwouldbegoodtoknowifthedatabaseis logicallyconsistentfromESE'sperspective(dothisvia"esentutl/g ntds.dit"). 3.AlsoafterweknowitislogicallyconsistentfromAD'sperspective(do thisvia,exactcommandlineprovided: ntdsutil"semdataanal""go""q""q" Cheers, BrettSh[msft] Ex-Building7GarageDoorOperator OnTue,20Jun2006,JoshuaCoffmanwrote: IhaveafewquestionsforyouADgurusoutthere!:) IjustranthroughaDisasterRecoverytestoftwoofourADsandI haveafewquestionswhichhavecomeupasaresultofthetest. ConfigurationNotes: TheseboxesareWindows2003,SP1. ThedomainswereoriginallyWindows2000domains. Thefollowingerrorspopupononeofthedomaincontrollersduring therestore. "CouldnotdisplaytheattributetypefortheobjectwithDNT 831424.Error:failedtogetdnofdnt831424"Thisoccursmanytimes throughouttherestore. NOTE:Thisisduringacompleterestore,e.g."authoritativerestore: restoredatabase"Ialsoseeafewofthese. "TherewasanerrorparsingtheGUIDfromthefileonline:1981"(Not tomanyofthese,maybefourorfive) Additionally,withSP1,LDIFfilesarecreatedtorestoreback-links. Thefilethatrestorestheuser/groupback-linksimportssuccessfully. Thefilethatrestorestheconfigurationback-linksfails.(sorry,I donothavetheerrorhandy) Theauthoritativerestoresaysitcompletedsuccessfully,andafterI gothroughmetadatacleanupandFSMOseizure,theboxstartsup withoutanyerrors,andADthrowsnoerrorsonstartup. Iwaswonderingifanyonecantellmewhattheseerrorsmean?What aretheirramifications?Howcantheerrorsberesolved. Thanks, Josh Listinfo:http://www.activedir.org/List.aspx ListFAQ:http://www.activedir.org/ListFAQ.aspx Listarchive:http://www.activedir.org/ml/threads.aspx
