none
Import von GPOs: Problem mit der MigrationTable RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    Ziel ist es, alle GPOs aus einer Produktivdomäin eine Testdomäne (beides Server 2003) zu migrieren. Alle GPOs in der Quelldomain sichere ich mit BackupAllGPOs.wsf und erstelle mir das Environment mit CreateXMLFromEnvironment.wsf. 

    In der Testdomain wird CreateEnvironmentFromXML.wsf und dann der Import mit ImportAllGPOs.wsf bzw. ImportGPO.wsf angestossen. Dabei wird eine Migrationstabelle benutzt.

    Das Problem ist, das der Import fehlschlägt bzw. fehlerhaft ist.

    Anhand einer GPO hier mal ein Beispiel:

    ImportGPO.wsf c:\temp GPO_IE_UAG /CreateIfNeeded /Domain:<domainname> /MigrationTable:c:\temp\uag.migtable

    In der Migtable ist nur ein UNC Pfad hinterlegt:

    <sourcepath>\scripts\settings.vbs   <destpath>\scripts\settings.vbs 

    Fehlermeldung: Error importing settings into GPO GPO_IE_UAG
    438 - Object doesn't support this property or method

    Ohne Migrationtable funktioniert der Import, allerdings ist dann der Parameter für das vbs LogonScript falsch.

    Liegt da meinerseits ein Gedankenfehler vor oder kann man gar nicht die Parameter mit der Migtable austauschen?

    Gruss Olaf

    Dienstag, 7. September 2010 11:52
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden


    Hi,

    Am 07.09.2010 13:52, schrieb Olaf_S:

    In der Testdomain wird CreateEnvironmentFromXML.wsf und dann der
    Import mit ImportAllGPOs.wsf bzw. ImportGPO.wsf angestossen.

    Warum?
    CreateEnvironmentfromXML macht all das schon. Es erstellt auch alle
    Gruppen die in den Filter auf tauchen.

    Du benötigst weder BackupAllGPOs noch Import irgendwas und schon gar
    keine Migrationstabelle.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Dienstag, 7. September 2010 13:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Mark,

    ok ich erstelle in der Quelldomain das XML-File mit CreateXMLFromEnvironment.wsf ...

    In der Testdomain starte ich CreateEnvironmentfromXML <xmlfile>

    Das Script erstellt auch brav in der Testdomain alle GPOs und verlinkt diese; die Settings sind allerdings alle leer.

    Es gibt aber auch viele Fehlermeldungen bei der Ausführung von CreateEnvironmentfromXML wenn die SecurityGroup Nodes oder die Group Memberships verarbeitet werden. Irgendwann bricht das Script mit "A referral was returned from the server" ab. Ist das die Ursache, dass die Settings nicht importiert werden?

    Gruss Olaf

    Dienstag, 7. September 2010 14:07
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 07.09.2010 16:07, schrieb Olaf_S:

    Das Script erstellt auch brav in der Testdomain alle GPOs und
    verlinkt diese; die Settings sind allerdings alle leer.

    Entweder verwendest du die GPMC Scripte für 2003 unter 2008 oder die
    GPMC Sample Scripts von 2008 unter 2003.
    Oder du hast in deinem 2003 GPOs GPPreferences verwendet, die du mit
    Win//2008 erstellt hast, dann kannst du diese GPOs auch nur mit den
    GPMC Scripten von 2008 exportieren und vor allem importieren.

    Auch gerne genommen:
    Du exportierst nach C:\GPOTest und zippst das ganze zu "testen.zip"
    und entpackst/ importierst dann die Dateien hinterher nach C:\Testen
    "C:\GPOTest" steht als Pfad hardcodiert im XML File ...

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Dienstag, 7. September 2010 16:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Nein, beide sind reine 2003 Domainen und GPPreferences werden nicht verwendet!

    IMHO müsste erst einmal geklärt werden, warum CreateEnvironmentFromXML.wsf mit einem Fehler abbricht (A referral was returned from the server) und die Settings nicht vorgenommen werden.

    Logfile:

    Created GPO und Created GPO Link --> OK

    Ein paar Fehler beim Erstellen der Security Gruppen gibt es. Ich kann die Gruppen allerdings händisch anlegen!  Attempt to create security group <groupname> failed.
    The error was 0x80072035

    Viele Fehler bei  "adding member to group" : OK, die User existieren noch nicht in der Testdomain

    Und dann bricht das Script ab mit besagter Fehlermeldung.

    Müssen denn alle User bereits vorher in der Testdomain migriert sein?

    Gruss Olaf

    Mittwoch, 8. September 2010 07:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 08.09.2010 09:25, schrieb Olaf_S:

    IMHO müsste erst einmal geklärt werden, warum
    CreateEnvironmentFromXML.wsf mit einem Fehler abbricht

    Keine Ahnung, ich habe es schon 1000fach gemacht in Produktion, Test
    und Workshop, es geht immer.

    Wie sieht denn deine Commandline für Ex/Import aus?
    Umlaute/Sonderzeichen in OU/User/Gruppen? Nicht gut ...

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 8. September 2010 09:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Umlaute /Sonderzeichen gibt es nicht.

    Export (in Produktiv Domain):

    cscript.exe $GPOScriptPath\CreateXMLFromEnvironment.wsf "$GPOBackupPath\Migration\$Domain.xml" /Domain:$Domain /TemplatePath:Z:\GPOBackup /q >$GPOBackupPath\Migration\CreateXMLFromEnvironment.log

    Import (in Test Domain):

    cscript.exe "$GPOScriptPath\CreateEnvironmentFromXML.wsf" /XML:"z:\Migration\$Domain.xml" /DC:$DC /Domain:$DestDomainName /q >$GPOBackupPath\Migration\CreateEnvironmentFromXML.log

    Z:\GPOBackup ist zu einem UNC Path gemappt. Dann funktioniert wenigstens auch der Import der Settings. Allerdings sind einige Settings Parameter nicht an die Zieldomain (UNC-Pfade) angepasst. Also doch eine Mig-table?

    Gruss Olaf

    Mittwoch, 8. September 2010 10:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 08.09.2010 12:17, schrieb Olaf_S:

    Export (in Produktiv Domain):
    cscript.exe $GPOScriptPath\CreateXMLFromEnvironment.wsf "$GPOBackupPath\Migration\$Domain.xml" /Domain:$Domain /TemplatePath:Z:\GPOBackup /q>$GPOBackupPath\Migration\CreateXMLFromEnvironment.log

    Hm, mach es mal lokal, nicht UNC und lass das Log inkl. /q weg.
    Gestern noch im Workshop, so gezeigt:

    Export ab einer OU
    cscript CreateXMLFromEnvironment.wsf c:\daten\gpoenv\dasdorf.xml /templatepath:c:\Daten\GPOEnv /StartingOU:"ou=das dorf,dc=gallier,dc=ads"

    Import:
    cscript CreateEnvironmentFromXML.wsf /xml:c:\daten\gpoenv\dasdorf.xml

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 8. September 2010 10:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    mit gemappten oder lokalen Laufwerken für die Datenablage funktioniert der Import soweit. Das Script bricht jetzt nicht mehr ab, die Settings werden übernommen.

    Bleibt jetzt nur noch das Problem der nicht angepassten Pfade, z.B. der Parameter für das Login Script.

    Gruss Olaf

     

    Mittwoch, 8. September 2010 11:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 08.09.2010 13:17, schrieb Olaf_S:

    Bleibt jetzt nur noch das Problem der nicht angepassten Pfade,

    Poste mal den Inhalt der MigTable

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 8. September 2010 11:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hier ein Auszug der Migrationtable:

    <?xml version="1.0" encoding="utf-16"?>
    <MigrationTable xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.microsoft.com/GroupPolicy/GPOOperations/MigrationTable">
      <Mapping>
        <Type>UNCPath</Type>
        <Source>\\(quelldomain)\SYSVOL\(quelldomain)\scripts\uk\uagstring.vbs</Source>
        <Destination>\\(testdomain)\SYSVOL\(testdomain)\scripts\uk\uagstring.vbs</Destination>
      </Mapping>
      <Mapping>
        <Type>UNCPath</Type>
        <Source>\\(quelldomain)\SYSVOL\(quelldomain)\scripts\uk</Source>
        <Destination>\\(testdomain)\SYSVOL\(testdomain)\scripts\uk</Destination>
      </Mapping>
    </MigrationTable>

    In (quelldomain) bzw. (testdomain) stehen natürlich dir richtigen vollständigten Domänenbezeichnungen. Ich hab in diesem Beispiel mal beide Varianten probiert.

    Gruss Olaf

    Mittwoch, 8. September 2010 13:18
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 08.09.2010 15:18, schrieb Olaf_S:

         <Source>\\(quelldomain)\SYSVOL\(quelldomain)\scripts\uk\uagstring.vbs</Source>
         <Destination>\\(testdomain)\SYSVOL\(testdomain)\scripts\uk\uagstring.vbs</Destination>

    Ich bin mir gerade nicht sicher, ob das NETLOGON im Export
    berücksichtigt wird.
    Hinterlege das Script zum Test wieder in den Logon ORdner der GPO.

    Ansonstne, wie hast du die MigTable erstellt? Per Hand oder automatisch?

    Sichere einmal die GPO mit dem Script, öffne mtedit und lass die Tabelle
    über Extras -> von Sicherung auffüllen.

    Ist das resultierende XML dann anders?

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Mittwoch, 8. September 2010 13:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    die Migrationtable habe ich per Script mit cscript CreateMigrationTable.wsf /AllGPOs ...  erstellt und dann die UNC Pfade angepasst.

    Es scheint so zu sein, dass wenn SYSVOL im Pfad enthalten ist, die Pfadumsetzung nicht funktioniert. Steht der NETLOGON Pfad drin, wird dieser angepasst.

    Bei der Validierung der MigrationTable in der Zieldomäne werden viele Warnungen angezeigt, u.a. das auf den Pfad \\(testdomain) nicht zugegriffen werden kann. Kann ich aber.

    Vermutlich muss ich bei dieser einen GPO dran denken, den Pfad händisch zu ändern.

    Alternativ kann sicherlich bevor CreateXMLFromEnvironment ausgeführt, die dazugehörige XML-Datei gpreport.xml per Script modifizieren. Vielleicht gibt es aber auch einen besseren Weg???

    Gruss Olaf

    Donnerstag, 9. September 2010 06:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 09.09.2010 08:19, schrieb Olaf_S:

    die Migrationtable habe ich per Script

    mal mtedit.exe probiert?

    Es scheint so zu sein, dass wenn SYSVOL im Pfad enthalten ist, die
    Pfadumsetzung nicht funktioniert. Steht der NETLOGON Pfad drin, wird
    dieser angepasst.

    \\deine.dom\NETLOGON ist ein funktioneller Pfad für GPO Scripte
    ändere es einfach ... ;-)

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Donnerstag, 9. September 2010 07:21
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Mark,

    \\deine.dom\NETLOGON ist ein funktioneller Pfad für GPO Scripte
    ändere es einfach ... ;-)

    Versteh ich nicht was damit gemeint ist :-(

    Mit Netlogon im Pfad funktioniert es ja, aber mit \\deine.dom\SysVol\deine.dom\.... eben nicht.

    GPOs in der Produktivdomain dahingehend zu ändern möchte ich vermeiden.

    Sichere einmal die GPO mit dem Script, öffne mtedit und lass die Tabelle
    über Extras -> von Sicherung auffüllen.

    Geht leider nicht mit Server 2003.

    Gruss Olaf

    Donnerstag, 9. September 2010 19:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    Am 09.09.2010 21:20, schrieb Olaf_S:

    \\deine.dom\NETLOGON ist ein funktioneller Pfad für GPO Scripte
    ändere es einfach ... ;-)
    Versteh ich nicht was damit gemeint ist :-(

    Scripte der GPO haben genau wie das klassische Anmeldescript von
    NT4 hardcodierte Pfade die erlaubt sind. Obiger gehört dazu, genau
    wie \\deine.dom\SysVol\deine.dom\scripts

    GPOs in der Produktivdomain dahingehend zu ändern möchte ich vermeiden.

    Warum? es ist nur ein Pfad. Wenn nur NETLOGON funktioniert im Export
    musst du mit dem "Fehler" leben oder eben diesen vermeiden.
    Vermeiden kannst du ihn nur indem du den "richtigen" PFad verwendest.

    /Sichere einmal die GPO mit dem Script, öffne mtedit und lass die Tabelle
    /über Extras ->  von Sicherung auffüllen.
    Geht leider nicht mit Server 2003.

    Natürlich geht das. mtedit -> extras -> "von sicherung auffüllen" oder
    "von gruppenrichtlinienobjekt auffüllen" ist immer schon bestandteil
    von mtedit.exe gewesen

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 10. September 2010 08:19
    |