Storage Migration Service Inventarisierung nicht möglich...

[3rdStar]

Moin,

bei dem Versuch meinen 2003 (SP2)-Server zu inventarisieren, kommt die Meldung: Die CIM-Sitzung konnte nicht hergestellt werden

Log SMS-Proxy Debug:
07.23.2019-13:05:17.231 [Erro] Failed device discovery stage VolumeInfo with error: (0xA00A) Could not establish CIM session with machine 'srv-file.blubblub.local' [d:\os\src\base\dms\proxy\discovery\discoveryproxy\DeviceDiscoveryOperation.cs::TryStage::1149]

Mit dem 2. File-Server (2012R2) gibt es keine Probleme bei dem Vorgang.

Jemand 'ne Ahnung?

3rd

 

[Whiterose]

Ich denke mal es liegt hier dran:
"new CIM cmdlets use the WSMan protocol by default, which isn’t supported on Windows Server 2003 "

 

[3rdStar]

Microsoft hebt aber extra hervor, dass die Migration der 2003er Server damit funktioniert

Zitat MS:

Anforderungen für den Quellserver

Der Quellserver muss es sich um eines der folgenden Betriebssysteme ausgeführt:

• WindowsServer Halbjährlicher Kanal
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2
• WindowsServer 2008
• Windows Server 2003 R2
• Windows Server 2003

 

[Whiterose]

Dann kannst du doch den MS Support in Anspruch nehmen, oder?

PS: Hier hatte es auch jemand versucht und ist auch gescheitert
https://www.virtualizationhowto.com...o-windows-server-2019-with-storage-migration/

 

[3rdStar]

Die Seite hatte ich noch nicht...

 

[snaxilian]

Das Migrationstool nutzt im Hintergrund ja auch "nur" PowerShell und ein bisschen WinRM Magie. Afaik brauchst für die sinnvolle Nutzung Powershell 2.0, dies ist aber bei 2003 nicht standardmäßig installiert, ist aber verfügbar.
Quelle u.a: https://powershell.org/forums/topic/is-it-possible-to-use-winrm-on-windows-2003/

Hier auch ein TechNet Artikel dazu wie man remote powershell management unter 2003 installiert: https://blogs.technet.microsoft.com...-managementall-servers-should-have-this-done/

Damit sollte die Migration dann passen. Bitte entsprechend auch Rückmeldung geben für den nächsten, der diesen Thread findet.

 

[3rdStar]

Danke für die Hinweise.
Jetzt werde ich mit:

Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt

konfrontiert.


Ich werde es Quick'n Dirty machen.....

 

[Layer8]

Oh mann, ich habe genau das gleiche Problem, allerdings bei Windows Server 2012 R2.

Ich habe alles unter "Anforderungen" in diesem Link gemacht, aber es funktioniert einfach nicht:
https://docs.microsoft.com/de-de/windows-server/storage/storage-migration-service/overview

Hast du es noch irgendwie hinbekommen?

 

[3rdStar]

Nein, liegt aber wohl an der Server-Version...

Hab eine 2019 Eval. benutzt, die kann das nicht.

und ~700,--€ Brutto nur für eine Migration auszugeben.... neeee

 

[.mojo]

entweder get-wmiobject verwenden oder die cim session mit -protocol DCOM initailisieren:

https://devblogs.microsoft.com/scripting/powertip-use-the-powershell-3-0-get-ciminstance-cmdlet/

 

[Layer8]

Okay, ich bin zu doof.

• Windows Admin Center läuft auf einer Windows 10 Rumpel.
• Den alten Fileserver Cluster (2012 R2) habe ich hinzugefügt.
• Den neuen Fileserver (2019) habe ich auch hinzugefügt.
• Auf Empfehlung habe ich einen extra Server als Orchestrator (auch 2019), über den die Migration stattfinden soll.

Muss ich vorab am Orchestrator die CIM Session per PowerShell starten und die Verbindung zu den 2012er Fileserver herstellen, und dann anschließend wieder im Admin Center den Scan versuchen?

Edit:
Hab es auf dem Orchestrator mal so wie in dem Link beschrieben gemacht, ein Get-CimSession wirft auch was aus. Bei ComuputerName steht einer der 2012er Rumpeln drin.

Leider kommt beim erneuten Scan immer noch der Fehler

 

[3rdStar]

ich zitier hier mal docs.microsoft.com:

• On all source servers and on any destination servers running Windows Server 2012 R2 or Windows Server 2016, in Windows Admin Center, connect to each server, go to Server Manager (in Windows Admin Center) > Firewall > Incoming rules, and then check that the following rules are enabled:
  • File and Printer Sharing (SMB-In)
  • Netlogon Service (NP-In)
  • Windows Management Instrumentation (DCOM-In)
  • Windows Management Instrumentation (WMI-In)
• If you're using third party firewalls, the inbound port ranges to open are TCP/445 (SMB), TCP/135 (RPC/DCOM endpoint mapper), and TCP 1025-65535 (RPC/DCOM ephemeral ports). The Storage Migration service ports are TCP/28940 (Orchestrator) and TCP/28941 (Proxy).
• If you're using an orchestrator server to manage the migration and you want to download events or a log of what data you transfer, check that the File and Printer Sharing (SMB-In) firewall rule is enabled on that server as well.

nachzulesen hier:
https://docs.microsoft.com/en-us/windows-server/storage/storage-migration-service/migrate-data

 

[Layer8]

Anhand der Anleitung bin ich eh schon vorgegangen.
Trotzdem danke.