2003 server migratie - SQL en shares overzetten?*

[Verwijderd]

Hoi Allemaal,
ik ben opzoeken naar oplossing voor een veilige migratie naar een nieuw omgeving.
Situatie:

- server 2003 ( met AD + Exchange 2003)
- SQL server 2005
- een storage met alle shares

er moet een nieuw server komen met een schoon installatie van 2003 server, exchange 2003 en ook sql 2005.

ik heb zelf een Virtual test omgeving opgezet met ongeveer zelfd situatie en probeerd een migratie uit te voeren.

maar ging niet helemaal zoals ik het wilde. met ADMT heb ik alle gebruikers, computers en groepen overgezet naar de nieuw omgeving. maar ik heb nu probleem met de shares.

de test omgeving wat ik gebruikt heb om de migratie van shares te kunnen testen:

- VM omgeving
- een VM disk

ik heb een nieuw Virtual Disk aangemaakt op een van de server en alle rechten ingesteld. maar als ik de AD migratie doet met ADMT en de Virtual Disk over zet naar de nieuwe server, is het niet meer geshared en alle rechten van de oude domain staat er nog.

weet iemand een oplossing hier voor? dat ik gewoon maar hele damain over kan zetten naar een nieuwe omgeving met alle rechten en shares?

ps: migratie van de exchange server, computers en gebruikers is wel gelukt. alleen nog de shares en SQL 2005.

alvast bedank
Gr. Saeed

[alt-92]

Servervarianten van Windows bespreken we in Windows Servers en Server-software

Ik verplaats je topic daarnaartoe.
Zo te zien heb je nog niet gekeken bij Microsoft zelf, zij hebben namelijk ook een Microsoft File Server Migration Toolkit

[Verwijderd]

Ik zou zelf:
- de nieuwe server in het oude domein joinen
- AD installeren
- alle FSMO roles overnemen
- de oude DC uitfaseren
- Exchange installeren op de nieuwe omgeving
- Mailboxen overzetten
- Oude exchange uitfaseren
- File en print migratie uitvoeren

In a nutshell

[Verwijderd]

alt-92 schreef op maandag 11 augustus 2008 @ 17:56:
Servervarianten van Windows bespreken we in Windows Servers en Server-software

Ik verplaats je topic daarnaartoe.
Zo te zien heb je nog niet gekeken bij Microsoft zelf, zij hebben namelijk ook een Microsoft File Server Migration Toolkit

ik heb wel naar de Microsoft File Server Migration Toolkit gekeken, maar is niet echt van toepassen voor mijn situatie.. want je kan alleen met de Microsoft File Server Migration Toolkit jou file server kopoeren naar ander lokatie en dat wil ik niet.

[Question Mark]

Verwijderd schreef op maandag 11 augustus 2008 @ 16:18:
maar ging niet helemaal zoals ik het wilde. met ADMT heb ik alle gebruikers, computers en groepen overgezet naar de nieuw omgeving. maar ik heb nu probleem met de shares.

Misschien handig dat je uitlegt wat precies je probleem is.

[Verwijderd]

Verwijderd schreef op maandag 11 augustus 2008 @ 19:41:
Ik zou zelf:
- de nieuwe server in het oude domein joinen
- AD installeren
- alle FSMO roles overnemen
- de oude DC uitfaseren
- Exchange installeren op de nieuwe omgeving
- Mailboxen overzetten
- Oude exchange uitfaseren
- File en print migratie uitvoeren

In a nutshell

Zo doe we het altijd. maar de probleem is dat we bang zijn dat de oud problemen meegenomen worden. bij een AD synchronisatie. is er misschien een tool waar je gewoon alle gebruikers en instellingen over kan zetten? en de zelfd ook voor exchange. want we hebben soms vreemd problemen met ons mail groepen.
Gr. Saeed

[ralpje]

Als je nou eerst eens aangeeft wat je problemen zijn, kunnen we misschien eens iets aan probleemoplossing doen, in plaats van symptoombestrijding?

'We gaan een nieuwe server installeren, want de mailgroepen doen af en toe vaag' vind ik een beetje kort door de bocht, namelijk.

[ Voor 31% gewijzigd door ralpje op 12-08-2008 08:27 ]

[Verwijderd]

we willen gewoon met een schone lei beginnen. want we hebben al heel wat upgrades gedaan en dat willen we niet meer. dus ik kan wel hier dat de problemen opnoemen maar dat is niet wat mijn vraag is.

Zou als jij het beschreef zijn we van NT4 naar 2000 gegaan. Van 2000 naar 2003, van 2003 naar 2003 R2, en van R2 naar R2 64bit.

Het leek ons verstandig om dus een keer een hele schone installatie te starten. Zonder dat problemen van oude installatie meegenomen worden.

Of is het 100% uitgesloten dat oude problemen bij een AD synchronisatie meegenomen worden?


Gr. saeed

[ Voor 46% gewijzigd door Verwijderd op 12-08-2008 08:38 ]

[Question Mark]

Beantwoord nu eerst eens wat er precies fout gegaan is met de "test-migratie"...

Je geeft aan dat je een migratie met een versie van ADMT gedaan hebt en dat er iets niet werkt met shares:

• Welke versie ADMT? (er zijn nl. meerdere)
• Vanuit wat voor omgeving (Domain en Forest level) migreer je en waar naar toe (Domain en Forest level)
• Trusts zijn goed aangemaakt?
• Wat staat er in de logfile van ADMT?
• Wat staat er in de eventlogs wat betrekking heeft op je problemen?

Welke procedure en stappen heb je precies gevolgd binnen de ADMT (sid history meegemigreerd?), je geeft aan dat je handmatig rechten hebt gezet. De ADMT zou dit echter voor je moeten doen...

[Verwijderd]

Wat ik gedaan heb is:
2 VM omgeving opgezet. ( 2 x 2003 server)
2 verschillende Domain ( als we echt gaan opgraden zal allebei het zelfd naam moeten krijgen)
ik heb de trust goed aangemaak. ( anders had ik geen gebruikers over kunnen zetten)
in ADMt ging de hele migratie goed. wat ik niet heb kunnen doen met de ADMT is de migreren van de filserver (rechten).
Ik heb ADMT versie 3 gebruikt.

in mijn eerst post staat procies wat ik allemaal gedaan heb.

[Verwijderd]

weet niemand hoe je zo`n situatie aan kan pakken? of hij/zij zal doen?
Gr. Saeed

[alt-92]

Ik zie je probleem niet zo eerlijk gezegd.
ADMT zet geen SQL en shares over, dat zal je zelf moeten doen.

Maar zo lastig lijkt me dat ook weer niet, FSMT kan voor je shares al een deel doen- en anders ga je het zelf scripten.
Shares aanmaken is niet lastig, en NTFS permissies overzetten met je data kun je ook goed met Robocopy afhandelen.

SQL database overzetten kun je ook goed in de Technet/MSDN documentatie terugvinden, dus ik ben heel benieuwd met de andere posters hier wat nou echt je issue is.

Ik denk zelf dat je je planning nog niet goed hebt

Verwijderd schreef op dinsdag 12 augustus 2008 @ 08:52:
2 verschillende Domain ( als we echt gaan opgraden zal allebei het zelfd naam moeten krijgen)

En dat kan dus niet, twee domains met identieke naamgeving

[ Voor 19% gewijzigd door alt-92 op 12-08-2008 17:24 ]

[Verwijderd]

Ik probeer het nogmals uit te leggen:
mijn oud domain moet op een nieuwe server komen, alle gebruikers moeten overgezet worden ( dat kan niet met de hand als je meer dan 200 gebruikers hebt. lijk me niet handig je kan makkelijk een fout maken. (dat is wel gelukt met ADMT)

over de shares, ik ga geen shares over zetten. ik heb een SAN Disk en moet overgezet worden naar de nieuwe server. mijn vraag is eigenlijk hoe doe je dat en als nog alle NTFS permissies wil behoud en dat alle gebruikers weer bij de Files kunnen zoals het was (in verband met SID).

Als ik een nieuw server installeerd en de SAN Disk overzet dan klopt de SID niet meer voor de rechten op alle Files ( ik heb hier over meer dan 200 Files. niet te doen met de hand).

Is er misschien een tool waar mee ik dat kan doen? dus de oud permissies van de gebruikers weer op de nieuwe domain kan gebruiken.

over de naam van de server, je heb gelijk. ik ga eerst ander namen geven en na de migratie ga ik weer de naam veranderen.

als mijn verhaal nog niet duidelijk is dan weet ik ook niet hoe ik het uit moet leggen.

GR. Saeed

[ralpje]

Verwijderd schreef op woensdag 13 augustus 2008 @ 08:31:
Ik probeer het nogmals uit te leggen:
mijn oud domain moet op een nieuwe server komen,

Server ernaast, DC maken, FSMO rollen overzetten, oude server demoten, klaar?

[Verwijderd]

Ok, zo hebben wij alle upgrades / migraties in het verleden ook gedaan. (zoals ergens hierboven al uitgelegd) maar....

als je dit nou NIET wilt! (Om er zeker van te zijn dat je geen oude problemen meeneemt vanuit de bestaande Active Directory.) Je wilt dus een volledige nieuwe active directory opbouwen naast je bestaande omgeving. Daarna gebruikers eventueel migreren. (of mij part met de hand aanmaken, wat dan ook)

Daarna komt er een moment dat we onze SANs loskoppelen van het bestaande netwerk en koppelen aan het nieuwe netwerk. Dan klopt er dus niks meer van de bestaande file-security. Is er een mogelijkheid om dit te herstellen?

1 of andere tool die dus je file-security weer in orde maakt.
Of komt het nooit voor dat bestaande problemen meegenomen worden met een migratie-procedure zoals door jou beschreven?

Meer dan dat vraag ik niet.

[ Voor 7% gewijzigd door Verwijderd op 13-08-2008 08:54 ]

[ZeRoC00L]

Met ADMT kun je ook je SID-history overzetten, dus zouden NTFS rechten ook overgezet moeten worden. Kijk even in de documentatie van ADMT hoe je de SID history over kunt zetten.

[alt-92]

Verwijderd schreef op woensdag 13 augustus 2008 @ 08:42:
als je dit nou NIET wilt! (Om er zeker van te zijn dat je geen oude problemen meeneemt vanuit de bestaande Active Directory.) Je wilt dus een volledige nieuwe active directory opbouwen naast je bestaande omgeving. Daarna gebruikers eventueel migreren. (of mij part met de hand aanmaken, wat dan ook)

Een Clean & pristine 'migratie' dus.

Daarna komt er een moment dat we onze SANs loskoppelen van het bestaande netwerk en koppelen aan het nieuwe netwerk. Dan klopt er dus niks meer van de bestaande file-security. Is er een mogelijkheid om dit te herstellen?

Nee.
Domain weg = sIDs weg = geen toegang.

1 of andere tool die dus je file-security weer in orde maakt.
Of komt het nooit voor dat bestaande problemen meegenomen worden met een migratie-procedure zoals door jou beschreven?

Meer dan dat vraag ik niet.

Dat snap ik wel, maar dan mist er iets heel belangrijks in je hele migratieprocedure en planning.
Heb je inzichtelijk welke groepen er nu op je Data (NTFS én evntueel sharerechten) staan?

Wil je gaan rationaliseren?
Wil je gelijk gaan opschonen?
Of gewoon alles één op één overknallen?

[Verwijderd]

bedank alt-92 voor de post.
dat is procies wat ik wil een Clean en Pristine migratie.

Ik wil gaan rationaliseren en opschonen.

En ik weet wel welke groepen allemaal rechten hebben op de Datas en NTFS-shares.

wat ik nu wil weten is hoe ik de rechten op al de files moet regelen na de nieuw installatie.

Gr. Saeed

[Verwijderd]

Is het geen optie om de filestructuur opnieuw te bouwen en rechten te configureren? Weet niet hoe groot ze zijn maar als je toch opnieuw wil beginnen...

Anders zal je met ADMT+sid migratie, en robocopy of SecureCopy aan de slag moeten.

[Verwijderd]

filestructuur opnieuw bouwen en rechten configureren is geen opstie als je meer dan 200 Files heb en allemaal verschillende rechten. Robocopy of SecureCopy is ook geen optie want ik ga geen files overzetten (ik heb San disk en die wordt dan verplaats naar de nieuw server). maar tog bedank voor de post. Ik ga kijken of we dat anders kunnen doen.

[Verwijderd]

dan hoef je toch alleen met ADMT de sids mee te nemen?

[Verwijderd]

daar zit wel wat in. Ik ga proberen. Tinx:)

[alt-92]

Verwijderd schreef op woensdag 13 augustus 2008 @ 15:33:
filestructuur opnieuw bouwen en rechten configureren is geen optie als je meer dan 200 Files heb en allemaal verschillende rechten.

Je weet de rechten al, want die heb je in kaart gebracht.
Ik vermoed dat je shares bedoelt met die 200, en dan is het sowieso al aan te raden om daar eens verstandiger naar te kijken.
Standaardiseren en uitzonderingen zoveel mogelijk afschaffen.

Robocopy of SecureCopy is ook geen optie want ik ga geen files overzetten (ik heb San disk en die wordt dan verplaats naar de nieuw server).

En waarom geen move doen naar een vers ingericht deel?
Die SAN zit niet vol denk ik, dus je zou zelfs een gefaseerde move naar nieuw be-ACLde shares kunnen doen.


sIDhistory is iets wat je verdomd goed in de gaten moet houden, want een half jaar verder is iedereen het vergeten en nóg een jaar later komt het als een boemerang terug in je gezicht.

* alt-92 been there done that

[ Voor 11% gewijzigd door alt-92 op 13-08-2008 17:02 ]

[Verwijderd]

alt-92 schreef op woensdag 13 augustus 2008 @ 17:00:
[...]

sIDhistory is iets wat je verdomd goed in de gaten moet houden, want een half jaar verder is iedereen het vergeten en nóg een jaar later komt het als een boemerang terug in je gezicht.

* alt-92 been there done that

waarom is dat?

[albert04]

Hmm ziet de nieuwe server zichzelf wel al een domaincontroller + global catalog server?
Heb je event id 1119 of 1869 ontvangen in Directory service?

Zo niet, dan ben je nog niet klaar met de eerste stap van de migratie. De event moet je eerst krijgen voordat je begint met de bestanden en/of mailboxen migratie.

[alt-92]

Verwijderd schreef op woensdag 13 augustus 2008 @ 17:09:
waarom is dat?

Wat ik al eerder zei:

alt-92 schreef op woensdag 13 augustus 2008 @ 13:13:
Domain weg = sIDs weg = geen toegang.

sIDHistory is leuk tijdens je transitiefase, omdat het transparant werkt voor je eindgebruikers maar het is een behoorlijk obstakel als je dingen moet gaan opruimen.

Ik zou het liever vermijden in een (grotere) produktieomgeving en de security groepen óf daadwerkelijk met ADMT overzetten, óf gelijk voor de fileshares nieuwe groepen en ACLs implementeren.

Kun je gelijk vervuiling eruit halen en lastige groepnesting vraagstukken aanpakken.

[Verwijderd]

Ik ben nog niet begonnen met migratie. ik wil eerst weten wat de mogelijk allemaal zijn. wat ik nu heb is een test omgeving waar ik verschillende tools probeer

[Verwijderd]

alt-92 schreef op woensdag 13 augustus 2008 @ 18:38:
[...]

Wat ik al eerder zei:


[...]

sIDHistory is leuk tijdens je transitiefase, omdat het transparant werkt voor je eindgebruikers maar het is een behoorlijk obstakel als je dingen moet gaan opruimen.

Ik zou het liever vermijden in een (grotere) produktieomgeving en de security groepen óf daadwerkelijk met ADMT overzetten, óf gelijk voor de fileshares nieuwe groepen en ACLs implementeren.

Kun je gelijk vervuiling eruit halen en lastige groepnesting vraagstukken aanpakken.

Oke als ik al jouw post goed begrijp, is het verstandig om in zo`n situatie gewoon alles opnieuwe doen?

[alt-92]

Dat ligt eraan hoeveel werk je verwacht.

Maar om je een praktijkgeval te geven waarbij sIDHistory gebruikt werd:

Ik ben een keer bij een migratietraject gehaald waar ze van hun oude 2000 AD naar een 2003 AD gemigreerd zijn en gebruik hebben gemaakt van de sIDHistory feature.
De AD migratie met users/groepen was anderhalf jaar terug gedaan, en men wilde het oude domain uitzetten.
Daarvoor moesten alleen nog twee DFS rootservers uit het oude domain worden opgeruimd, de oude fileservers uitgezet en daarna de domain controllers.

Uit de analyse van alle NTFS ACLs bleek dat zowel in de oude als de nieuwe omgeving de 'oude' groepen met sIDHistory gebruikt werden, en in ongeveer de helft (!) van de gevallen was de data overgezet met enkel de bestaande security groepen intact *die uit het oude domain*.

Door de sIDhistory konden gebruikers dus gewoon bij die shares komen, maar zodra je de oude DC uit zou zetten wordt de security groep op de data zelf niet meer resolved en kun je er niet meer bijkomen met je nieuwe account.

Dan loop je dus een risico op een Denial of Service. Voorkomen is dan beter dan genezen toch?

[mbaltus]

Of je gebruikt xcacls.exe om de rechten op files "om te catten", maar dat vergt wel wat scripting en een goede planning/aanpak vooraf om alle rechten en bijbehorende groepen in kaart te hebben.

Shares opnieuw aanmaken wordt scripten (bijv. via een batch file met net share commando's, etc.).

Voor wat TS wil is er niet één standaard tool die automatisch dat allemaal even uitvoert. Diverse keren vergelijkbare migraties gedaan en regelmatig veel tijd in voorbereiding gestopt om scripts, etc. te bouwen hiervoor.