none
VAMT 2.0 "Die Verbindung mit dem Remoteserver kann nicht hergestellt werden" RRS feed

  • Frage

  • Hallo, normalerweise aktivieren wir unsere Win7-Clients über KMS, haben aber auch ein paar Notebooks, die selten am Netz sind und deshalb über MAK aktiviert werden sollen - also bleibt da an sich nur VAMT, wenn man das Ganze halbwegs zentralisieren will. Das VAMT läuft auf dem KMS-Server mit, welcher auch die entsprechenden Proxyfreischaltungen zu *.microsoft hat.

    Gebe ich jetzt im VAMT unseren VL-MAK Productkey ein, so funktioniert das Verify noch problemlos. Versuche ich dann aber, über "Refresh Product Data online" die Remaining activations abzuholen, bekomme ich obigen Fehler. Dementsprechend bekomme ich denselben Fehler, wenn ich versuche, die Clients per Proxy-Aktivierung zu aktivieren. Der Key lässt sich noch auf den Client bügeln, also funktioniert die Kommunikation zum Client. Was könnte hier noch im Argenliegen?

    Grüße

    Thomas

    Freitag, 29. Juni 2012 05:51

Antworten

  • Am 02.07.2012 schrieb Theo61:

    Muss mich noch mal korrigieren. Nachdem ich die Kiste noch mal rebootet habe, funktioniert das wieder ... Hatte eigentlich immer gedacht, dass UAC abschalten sofort greift.

    Nein, tut es nicht. Genau deshalb kommt ja auch in der Taskleiste auf
    der rechten Seite eine Meldung das ein Neustart erforderlich ist.

    Aber ich kann ja nun schlecht überall UAC abschalten. Oder ist das in solchem Fall wirklich das einzige Mittel?

    Wenn die Benutzer keine Adminrechte haben, kannst Du UAC abschalten.
    Was soll daran falsch sein? Bei XP hast Du auch keine UAC ab- oder
    anschalten können, wenn Du als Admin angemeldet warst.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 2. Juli 2012 18:35
  • Ok, überzeugt.

    Habe jetzt auf dem MAK-Proxy ein Script erstellt, welches die Notebooks entsprechend "unattended" aktivieren soll:

    rem 1. Gerät einlesen
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /a /computers %pc% /o %pf%\01.cil

    rem 2. Infos vom Gerät abholen

    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /r /i %pf%\01.cil /o %pf%\01.cil /user admin /password xxxxxxx

    rem 3. Key installieren
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /p /i %pf%\01.cil /o %pf%\02.cil /key xxxx-xxxx-xxxx-xxxx-xxxx /user admin /password xxxxxxxx
    rem 4. Anhand der Install. ID wird bei MS eine Confirmation ID (CID) geholt und in die CIL  hinzugefügt
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /u /i %pf%\02.cil /o %pf%\03.cil
    rem 5. Die mit allen notwendigen Infos (CID) befüllte CIL wird an den PC gesendet und derselbe aktiviert
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /c /i %pf%\03.cil /o %pf%\04.cil /user admin /password xxxxxxxxx

    Mal schauen, ob das so funzioniert...

    Einstweilen danke für die Hilfe!

    Grüße Theo


    Dienstag, 3. Juli 2012 10:04

Alle Antworten

  • Hab's mittlerweile hinbekommen ....  Zum einen war eine Proxyeinstellung fehlerhaft und zum Anderen bin ich mittlerweile auf den wohl bekannten VAMT2,0 - Bug gestoßen. Also vor VAMT-Start in den Regionaleinstellungen das Dezimaltrennzeichen von Komma auf Punkt ändern.

    Da VAMT 2 ja schon ne ganze Weile draußen ist, hätte dieser üble Fehler eigentlich schon mal behoben werden können ...

    Schönes WE allerseits

    Thomas
    • Als Antwort vorgeschlagen ChrisBeKa Mittwoch, 17. Juni 2015 13:26
    • Nicht als Antwort vorgeschlagen ChrisBeKa Mittwoch, 17. Juni 2015 13:26
    • Als Antwort vorgeschlagen ChrisBeKa Mittwoch, 17. Juni 2015 13:26
    Freitag, 29. Juni 2012 08:04
  • Es ist wie verhext - mit einem Mal geht das wieder nicht. Bekomme jetzt permanent der Fehler "Zugriff verweigert", wenn ich auf den Client zugreifen will. Aktiviere ich auf dem Client den lokalen Administrator und nehme die Credentials von dem, funktioniert es. Nehme ich die Credentials von einem anderen lokalen User - der auch Mitglied der Administratorengruppe ist - verweigert der Client mir den Zugriff. An WMI und DCOM kanns damit ja nicht liegen. Was könnte das wieder sein??

     

    Freitag, 29. Juni 2012 12:48
  • Am 29.06.2012 schrieb Theo61:

    Es ist wie verhext - mit einem Mal geht das wieder nicht. Bekomme jetzt permanent der Fehler "Zugriff verweigert", wenn ich auf den Client zugreifen will. Aktiviere ich auf dem Client den lokalen Administrator und nehme die Credentials von dem, funktioniert es. Nehme ich die Credentials von einem anderen lokalen User - der auch Mitglied der Administratorengruppe ist - verweigert der Client mir den Zugriff.

    Wird der Zugriff auch verweigert, wenn Du UAC abschaltest?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Sonntag, 1. Juli 2012 14:51
  • Hallo Winfried,

    ja, wird auch dann verweigert.

    VG Thomas

    Montag, 2. Juli 2012 09:43
  • Hi Theo,

    das Problem hatte ich leider auch.

    Ich habe per GPO den Adminuser umbenannt...danach war schluss per remote etwas per slmgr oder VAMT zu machen.

    (Ich habe leider keine Lösung gefunden: http://social.technet.microsoft.com/Forums/en-US/windows_Serverde/thread/0f9d7739-06db-4e55-9239-17aeaed66d68)

    Da ich jedoch sicherheit vorziehe, habe ich das Problem anschließend umgangen indem ich mit PSEXEC meine SLMGR Tasks durchgeführt habe auf den Hosts...das ganze in einem Script und man braucht für 100Server auch nicht mehr lange.

    Mfg. Chris

    Montag, 2. Juli 2012 09:48
  • Muss mich noch mal korrigieren. Nachdem ich die Kiste noch mal rebootet habe, funktioniert das wieder ... Hatte eigentlich immer gedacht, dass UAC abschalten sofort greift.

    Aber ich kann ja nun schlecht überall UAC abschalten. Oder ist das in solchem Fall wirklich das einzige Mittel?

    @Chris: Wie hast Du das genau gescriptet, wenn ich fragen darf?

    Montag, 2. Juli 2012 10:01
  • del status.txt /q
    set scriptpath=C:\domain\scripts\serversEU\get_lizenzstatus
    
    for /F %%f IN (C:\domain\scripts\serversEU\iplisten\allips.txt) DO @(
    c:\domain\tools\wintools\psexec.exe \\%%f cscript slmgr.vbs -dli | find "Name: Windows Server(R), Server" >%scriptpath%\osstatus.txt
    type %scriptpath%\osstatus.txt
    for /F "tokens=4 delims= " %%i IN (%scriptpath%\osstatus.txt) DO @(
    if %%i==ServerStandard call :standardactivation %%f
    if %%i==ServerEnterprise call :enterpriseactivation %%f
    )
    )
    
    for /F %%f IN (C:\domain\scripts\serversEU\iplisten\allips_specialDB.txt) DO @(
    c:\domain\tools\wintools\psexec.exe \\%%f cscript slmgr.vbs -dli | find "Name: Windows Server(R), Server" >%scriptpath%\osstatus.txt
    type %scriptpath%\osstatus.txt
    for /F "tokens=4 delims= " %%i IN (%scriptpath%\osstatus.txt) DO @(
    if %%i==ServerStandard call :standardactivation %%f
    if %%i==ServerEnterprise call :enterpriseactivation %%f
    )
    )
    
    
    for /F %%f IN (C:\domain\scripts\serversEU\iplisten\ter_t1.txt) DO @(
    c:\domain\tools\wintools\psexec.exe \\%%f cscript slmgr.vbs -dli | find "Name: Windows Server(R), Server" >%scriptpath%\osstatus.txt
    type %scriptpath%\osstatus.txt
    for /F "tokens=4 delims= " %%i IN (%scriptpath%\osstatus.txt) DO @(
    if %%i==ServerStandard call :standardactivation %%f
    if %%i==ServerEnterprise call :enterpriseactivation %%f
    )
    )
    
    
    exit
    
    :enterpriseactivation
    echo %1
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -dli | find "CPX3Y" >%scriptpath%\keystatus.txt
    for /F %%i IN (%scriptpath%\keystatus.txt) DO @(
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ato
    goto :next
    )
    echo nonext
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ipk 489j6-vhdmp-x63pk-3k798-cpx3Y
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ato
    :next
    goto :eof
    
    exit
    
    :standardactivation
    echo %1
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -dli | find "R7VHC" >%scriptpath%\keystatus.txt
    for /F %%i IN (%scriptpath%\keystatus.txt) DO @(
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ato
    goto :next
    )
    echo nonext
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ipk YC6KT-GKW9T-YTKYR-T4X34-R7VHC
    c:\domain\tools\wintools\psexec.exe \\%1 cscript slmgr.vbs -ato
    :next
    goto :eof

    relativ simple..und funktioniert.

    gut wir fragen mittels Nagios noch die verbleibende Zeit und den Status ab, somit würden wir einen Problemserver wohl hoffentlich feststellen.

    Mfg. Chris

    Montag, 2. Juli 2012 10:36
  • Am 02.07.2012 schrieb Theo61:

    Muss mich noch mal korrigieren. Nachdem ich die Kiste noch mal rebootet habe, funktioniert das wieder ... Hatte eigentlich immer gedacht, dass UAC abschalten sofort greift.

    Nein, tut es nicht. Genau deshalb kommt ja auch in der Taskleiste auf
    der rechten Seite eine Meldung das ein Neustart erforderlich ist.

    Aber ich kann ja nun schlecht überall UAC abschalten. Oder ist das in solchem Fall wirklich das einzige Mittel?

    Wenn die Benutzer keine Adminrechte haben, kannst Du UAC abschalten.
    Was soll daran falsch sein? Bei XP hast Du auch keine UAC ab- oder
    anschalten können, wenn Du als Admin angemeldet warst.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 2. Juli 2012 18:35
  • Ok, überzeugt.

    Habe jetzt auf dem MAK-Proxy ein Script erstellt, welches die Notebooks entsprechend "unattended" aktivieren soll:

    rem 1. Gerät einlesen
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /a /computers %pc% /o %pf%\01.cil

    rem 2. Infos vom Gerät abholen

    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /r /i %pf%\01.cil /o %pf%\01.cil /user admin /password xxxxxxx

    rem 3. Key installieren
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /p /i %pf%\01.cil /o %pf%\02.cil /key xxxx-xxxx-xxxx-xxxx-xxxx /user admin /password xxxxxxxx
    rem 4. Anhand der Install. ID wird bei MS eine Confirmation ID (CID) geholt und in die CIL  hinzugefügt
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /u /i %pf%\02.cil /o %pf%\03.cil
    rem 5. Die mit allen notwendigen Infos (CID) befüllte CIL wird an den PC gesendet und derselbe aktiviert
    "%ProgramFiles(x86)%\VAMT 2.0\vamt.exe" /c /i %pf%\03.cil /o %pf%\04.cil /user admin /password xxxxxxxxx

    Mal schauen, ob das so funzioniert...

    Einstweilen danke für die Hilfe!

    Grüße Theo


    Dienstag, 3. Juli 2012 10:04
  • Hallo Raul,

    sorry für die späte Antwort. Ja, nach langer Probiererei klappt es mittlerweile. Letzter Stolperstein war, dass ich immer den Fehler

    VAMT reported that the response from the activation server did not match the request

    bekommen habe. Ursache war hier wieder dieser dämliche Trennzeichen-BUG. Hatte das zwar korrekt eingestellt, aber nicht beachtet, dass ich ja das Skript mittels psexec im Kontext eines Dienst-Accounts laufen lasse und deshalb das in dessen Userprofile auch noch eingestellt werden muss ...

    Ein letztes Problem habe ich allerdings noch - vielleicht hat da jemand noch einen Tipp: Da ich ja nun viel herumprobiert habe und ein und dieselbe Testmaschine mehrfach aktiviert habe, musste ich feststellen, dass meine MAK-Lizenzen immer fröhlich weniger werden. Hatte eigentlich gelesen, dass bei derselben Installations-ID und demenstprechend auch derselben Conf.-ID keine zusätzliche Lizenz drauf geht. Oder mache ich da noch was falsch?

    Grüsse

    Thomas

    Montag, 23. Juli 2012 08:15
  • Sicher das die ID´s immer gleich geblieben sind?

    slgmr -dlv ?

    Mit freundlichen Grüßen

    Chris

    Montag, 23. Juli 2012 20:15
  • Ja, sind absolut identisch.

    Dienstag, 24. Juli 2012 08:38