[windows2000]sysvol folder op dc2 niet op goede locatie

[mutsje]

Ik zal het probleem duidelijk proberen te omschrijven.

Beide machines zijn Windows2000 met SP3

Er zijn 2 Domain Controllers welke met elkaar repliceren.
DC1 en DC2

DC1 sysvol locatie is de normale plaats namelijk c:\winnt\sysvol\ deze is ook goed geshared.
DC2 sysvol locatie is foutief. c:\winnt\system32\sysvol\ hier wordt sinds enige tijd naar toe gerepliceerd maar deze is NIET geshared... De originele sysvol staat er ook nog c:\winnt\sysvol en is WEL geshared maar er wordt niet naar toe gerepliceerd.

Welgeteld hebben we 2 technet articles hier over kunnen vinden. De eerste had alleen betrekking tot windows2000 servers sp1&sp2. De 2e had betrekking tot windows2000SP3(Q291823)

De bedoeling is op DC2 de replicatie weer naar de normale sysvol locatie gaat plaats vinden echter is het niet te vinden welk instelling je moet veranderen.

[luckyme_]

Hier staat een en ander over het moven en veranderen van de Sysvol. (ff scrollen naar "Moving Sysvol manually"
Misschien per ongeluk het verkeerde pad opgegeven tijdens dcpromo? Beetje maf dat het zomaar verandert.

[Verwijderd]

heeft dit wel gewerkt ?
of is dit altijd zo geweest ?

staan er specifieke foutmeldingen in de event viewer onder file replication service ?

[mutsje]

probleem is dat er nu 2 locaties zijn met sysvol. eentje die niet geshared is maar de data ontvangt en de originele die wel normaal geshared is (dus tijdens dcpromo aangemaakt is) maar niets ontvangt. Hoe ze dit voor elkaar gekregen hebben god knows wij staan voor een raadsel.

ik zit nu het article te lezen van luckyme. hopelijk brengt dit ons een stap dichter bij de oplossing . we gaan nu een testcase opzetten en eens spelen met de sysvol folders.

We gaan nu dus handmatig proberen sysvol's te moven en opnieuw active te maken. hopelijk gaat dit werken.

[ Voor 11% gewijzigd door mutsje op 21-05-2003 13:37 . Reden: extra info ]

[Question Mark]

Snelste oplossing is om op de foutieve DC Dcpromo te draaien en deze te demoten. Vervolgens draai je nog een keer Dcpromo en voila.

Dit is volgens mij ook verreweg de netste oplossing.

Zorg er wel voor dat de juiste DC global catalog gemaakt is voor het demoten van de DC

[Brahiewahiewa]

Question Mark schreef op 21 mei 2003 @ 13:52:
Zorg er wel voor dat de juiste DC global catalog gemaakt is voor het demoten van de DC

En denk er even om dat je de andere FSMO rollen moved naar de overblijvende DC

[mutsje]

Ja de snelste oplossing is inderdaad demoten en promoten. Maar we gaan nu eerst in testlab proberen deze situatie te creeeren anders gaan we of een non authoritive mode opstarten en move van sysvol uitvoeren of als bovengenoemd de DC2 demoten.
We gaan idd alle roles op DC1 zetten.. staan ze volgens mij ook het is niet mijn klant ik kop dit alleen richting de juiste beheerder maar vind het wel erg leerzaam.

[Question Mark]

FSMO rollen worden automatisch overgezet naar de meest geschikte server. Indien een server die gedemote wordt, een FSMO rol heeft zoekt het OS naar een 'vervangende' server.

k ben het met bra* eens dat het netter is om eerst handmatig de rollen over te zetten en vervolgens te controleren of elke andere DC of client (en netwerkservices zoals Wins/DNS) bijgewerkt worden voor het afbreken van de DC.

[Question Mark]

In knowledge base artikel Q255690 staat precies verteld hoe het overzetten van de rollen gedaan kan worden... Let er op dat je voor het overzetten van de "Schema-master-rol" je lid moet zijn van de groep "schema-admins".

Dat laatste kostte mij een keer 20 minuten zoeken.. ahum...

[mutsje]

We zijn enterprice admins.. dus we hebben alle rechten......

De eerste keer verplaatsen van sysvol heeft geresulteerd in een domain zonder sysvols lol... we gaan vandaag weer domain opbouwen thank god for testlabs

[Question Mark]

Precies wat ik bedoel...

Lid zijn van de groep Enterprise Admin maakt je nog geen Schema Admin, hiervoor moet je lid zijn van de groep "Schema Admins". MS heeft dit express gedaan omdat rechtstreeks de schema-database wijzigingen ontzettend tricky is.

[mutsje]

Linkd uit de resource kit is gebruikt op de testmachines. het verplaatsten gaat perfect. Het blijkt ook als je een copy van de sysvol trekt de machine daar ook vrolijk naar toe gaat replicaten.

[ Voor 3% gewijzigd door mutsje op 22-05-2003 14:04 . Reden: foutieve informatie verwijderd ]

[Question Mark]

Mutsje,

Hoe kom je aan dlink.exe. Ik heb even gezocht in de resource kit van 2000. Ik kan het hierin niet vinden. Ook de support tools van W2K zit deze tool niet.

Een snelle zoek op google levert ook niets op. Zoeken op de MS site levert ook niets op... Het is wel een errug handige tool zoals je het verteld...

Heb je een link waar dlink te downloaden is??

[mutsje]

ik zal ff verifieren met colega of ik naam wel weer us goed gespeld heb. Na me mail ff gechecked te hebben precies wat deze prutser al dacht....... hier is de microsoft text waar het precies om gaat

To import the SYSVOL folder structure

1. Use Windows Explorer to delete the existing %systemroot%\SYSVOL folder that you are rebuilding.

2. Connect to the Admin$ share on the domain controller that you identified earlier as the replication partner from which you plan to copy the SYSVOL folder structure.

3. Once you are connected to the Admin$ share point, verify that a folder labeled SYSVOL appears. Right-click the SYSVOL folder and click Copy.

4. In the same directory find some blank space and right-click. Click Paste. You might see a dialog box stating that some files already exist and a prompt asking whether you want to continue copying the folder. At each such prompt, click No.

5. Verify that the original SYSVOL folder and a new folder labeled Copy of SYSVOL both appear. Right-click on Copy of SYSVOL and click Rename. Type SYSVOL2 and press ENTER.

6. Open a command prompt. Change to the drive letter that represents the connection to the remote domain controller where you created the SYSVOL2 folder.

7. Change directory to SYSVOL2\sysvol.

8. Type DIR and press ENTER. Verify that <JUNCTION> appears in the DIR output and is followed by the name of the domain.

9. You must update the path in this junction so that it points to the new location. Type the following command:

linkd junctionname newpath

where newpath is the New Value you recorded in row four of Table B.1 while gathering the system volume path information. Press ENTER

10. If the Staging Area has been relocated and is no longer inside the SYSVOL folder, skip steps 10 and 11 and proceed to step 12. At a command prompt, change directory to \SYSVOL2\staging areas under the copy of SYSVOL that you created. Type DIR to list the contents and verify that <JUNCTION> appears in the DIR output.

11. Update the junction so that it points to the new location. Type the following command:

linkd junctionname newpath

where newpath is the New Value that you recorded in row five of Table B.1 while gathering system volume path information. Press ENTER.

12. At the command prompt, change back to the %systemroot% for the domain controller that you are repairing.

13. From the command prompt, use Xcopy to copy the contents of the \SYSVOL2 folder you created to a new SYSVOL folder on your local drive. Type the following command:

xcopy drive:\sysvol2\*.* sysvol\*.* /s /e /h /c /y

where drive is the letter representing the connection to the remote domain controller. Press ENTER.

14. Verify that the folder structure copied correctly. Compare the new folder structure to the SYSVOL (not the SYSVOL2) on the remote domain controller. Open a command prompt and use DIR to list the contents of the folders. Ensure that all folders exist.

15. Remove the SYSVOL2 folder that you created on the remote domain controller.

16. Disconnect from the remote domain controller. If you had to create a shared folder on that domain controller in order to connect to it, remove the shared folder. Some organizations consider it a security risk to retain shared folders that are not in use.

17. Restart the domain controller in normal mode.

[Question Mark]

Bovenstaand ben ik ook tegengekomen na een snelle zoek voor een oplossing.

Even een korte (gewetens)vraag:

Bovenstaand is vrij bewerkelijk en tijdrovend, was het dan niet makellijker geweest om gewoon te demoten en promoten???

[mutsje]

We zijn beide opties aan het testen en afwegen. Let wel we praten hier over een productie omgeving met paar honderd gebruikers erop dus we gaan voorlopig nog even testen voordat we het op een productie omgeving waar je het maar 1 keer goed kan doen loslaten. We krijgen sowieso hulp van microsoft technical support. Is erg handig als je partner van zo'n bedrijf bent

[ Voor 6% gewijzigd door mutsje op 23-05-2003 13:48 ]