Hallo Leute,
ich habe ein Installationsscript (Batch) welches ich vom OPSI aus ausführen möchte.
Dieses Intallationsscript greift auf eine Freigabe im Netzwerk zu welche sich auf unserem ERP-Server befindet.
So haben wir dies bisher auch immer installiert gehabt indem wir, als Domänen-Administrator, diese BAT-Datei ausgeführt haben die dann alles ziemlich vollautomatisch installiert hat was unseren ERP-Server betrifft (OpenEdge Progress-Treiber, Ghostscript, den Clienten usw.)
Jetzt wollte ich dies in opsi integrieren damit wir das auch 'herunterdrücken' können über den OPSI, zentral und ohne an die Client-PC hin laufen zu müssen.
Gesagt, getan... und auf die 'Schnautze' geflogen.
Das Script muss wohl als Administrator ausgeführt werden weil es auf den Netzwerkshare zugreift (der eben nur den Domänen-Administratoren zugänglich ist) und wahrscheinlich, irgendwo tief in seiner Komplexität, noch weitere Berechtigungen als solches benötigt.
Kurz eine Lösung überlegt und beschlossen dies mit runasspc.exe zu lösen.
Dieser befindet sich auch auf einem Netzshare, aber um sicherzugehen kopiere ich diese eine Datei in das CLIENT_DATA-Verzeichnis und greife dort auf die zuvor generierte SPC-Datei.
Dies hat aber leider auch nicht geholfen und das kann ich mir nicht erklären.
Nun gut, jetzt habe ich beschlossen hier nachzufragen wie ihr das handhabt wenn ihr in solche Lagen geratet?
Kann mir da jemand Tips geben wie ich eine Installation ausführen kann die Domänenberechtigung benötigt?
Schönen Gruß & Danke schon einmal im Voraus für eure Mühe!
Installations-Batch mit Domänen-Adminrechte ausführen
-
n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Re: Installations-Batch mit Domänen-Adminrechte ausführen
Hi,
ohne Log lässt sich schwer das Problem eingrenzen.
Ist es der Mount, das Ausführen der Dateien oder dass das Script nicht macht, was du dir vorstellst?
Ich würde versuchen die Mounterei eines anderen Shares vorerst weg zu lassen und das ganze auf dem opsi-Server als Produkt bereitstellen. Das löst dein Problem mit dem Mount als Domainmitglied und ist in meinen Augen eine sauberere Lösung als irgendwelche anderen Shares - die vllt sogar nicht mal unter Kontrolle des opsi-Admins stehen - zu mounten. Zumal du dann mit opsi auch nachvollziehen kannst welche Versionen der Software installiert wurden
Falls die Installations-Scripte sich nicht mit den System-Rechten des Client-Agent installieren lassen, dann würde ich mir die Vorlage zur Installation mit einem temp. Admin anschauen.
Viele Grüße
Niko
ohne Log lässt sich schwer das Problem eingrenzen.
Ist es der Mount, das Ausführen der Dateien oder dass das Script nicht macht, was du dir vorstellst?
Ich würde versuchen die Mounterei eines anderen Shares vorerst weg zu lassen und das ganze auf dem opsi-Server als Produkt bereitstellen. Das löst dein Problem mit dem Mount als Domainmitglied und ist in meinen Augen eine sauberere Lösung als irgendwelche anderen Shares - die vllt sogar nicht mal unter Kontrolle des opsi-Admins stehen - zu mounten. Zumal du dann mit opsi auch nachvollziehen kannst welche Versionen der Software installiert wurden
Falls die Installations-Scripte sich nicht mit den System-Rechten des Client-Agent installieren lassen, dann würde ich mir die Vorlage zur Installation mit einem temp. Admin anschauen.
Viele Grüße
Niko
Code: Alles auswählen
import OPSIRe: Installations-Batch mit Domänen-Adminrechte ausführen
@n.wenselowski
Das habe ich mir auch schon überlegt. Aber es ist höchst komplex das alles auseinander zu nehmen und dann einzeln mit den richtigen Parametern zu installieren.
So muss man nur diese Batch ausführen und alles wird erledigt.
Ich kann eine Log mitsenden, die wird abern icht viel bringen da keine Fehlermeldung ersichtlich ist. Die Batchdatei verursacht den Fehler und ich glaube nicht das opsi das als solches realisiert, oder?
Ich bin irgendwann mal hergegangen und habe ein 'test'-paket erstellt mit einer Batchdatei die lediglich von diesem betreffenden Share eine Datei lokal kopiert.
Dies klappt schon einmal nicht und daher behandeln wir doch diese. Wenn ich die zum laufen bringen kann, dann wird das auch mit allen anderen Batchdateien, sofern ich noch weitere hätte, was momentan aber nicht der Fall ist bis auf die Installationsbatch des ERP-Systems.
Ich mounte übrigens nichts manuell. In der Batchdatei wird direkt auf den Netzwerkshare zugegriffen (smb?) um sich dort Dateien zu holen oder Sonstiges gemacht wird.
Hier die Logdatei dieses Versuches von gerade eben mit meinem test-paket welches ein test.bat enthält welches wiederrum lediglich vom share eine Datei lokal kopiert. Wenn ich es in der CMD ausführe am Client funktioniert es unter Domänen-Adminanmeldung tadellos.
Als lokalen Admin oder User muss ich mich jedoch erst authentifizieren. Und das wird der springende Punkt sein wie ich vormals vermutete...
Das habe ich mir auch schon überlegt. Aber es ist höchst komplex das alles auseinander zu nehmen und dann einzeln mit den richtigen Parametern zu installieren.
So muss man nur diese Batch ausführen und alles wird erledigt.
Ich kann eine Log mitsenden, die wird abern icht viel bringen da keine Fehlermeldung ersichtlich ist. Die Batchdatei verursacht den Fehler und ich glaube nicht das opsi das als solches realisiert, oder?
Ich bin irgendwann mal hergegangen und habe ein 'test'-paket erstellt mit einer Batchdatei die lediglich von diesem betreffenden Share eine Datei lokal kopiert.
Dies klappt schon einmal nicht und daher behandeln wir doch diese. Wenn ich die zum laufen bringen kann, dann wird das auch mit allen anderen Batchdateien, sofern ich noch weitere hätte, was momentan aber nicht der Fall ist bis auf die Installationsbatch des ERP-Systems.
Ich mounte übrigens nichts manuell. In der Batchdatei wird direkt auf den Netzwerkshare zugegriffen (smb?) um sich dort Dateien zu holen oder Sonstiges gemacht wird.
Hier die Logdatei dieses Versuches von gerade eben mit meinem test-paket welches ein test.bat enthält welches wiederrum lediglich vom share eine Datei lokal kopiert. Wenn ich es in der CMD ausführe am Client funktioniert es unter Domänen-Adminanmeldung tadellos.
Als lokalen Admin oder User muss ich mich jedoch erst authentifizieren. Und das wird der springende Punkt sein wie ich vormals vermutete...
Code: Alles auswählen
(0)
(1) [1] [Jan 04 09:49:20:844] --
(2) [1] [Jan 04 09:49:20:844] --
(3) [1] [Jan 04 09:49:20:845] c:\opsi.org\log\\opsi-script-part-Ky09Ia90.log
(4) [1] [Jan 04 09:49:20:845] opsi-script 4.11.6.2 started at >>
(5) [1] [Jan 04 09:49:20:845] opsi-script log file with encoding utf8
(6) [1] [Jan 04 09:49:20:845] startmessage opsi-script created at CentralForm.FormCreate: 04.01.2017 09:49:20
(7) [1] [Jan 04 09:49:20:845] Loading skin from: C:\Program Files (x86)\opsi.org\opsi-client-agent\opsi-winst\winstskin
(8) [1] [Jan 04 09:49:20:845] startmessage StartProgramModes and create log: 04.01.2017 09:49:20
(9) [1] [Jan 04 09:49:20:845] pm: 5 04.01.2017 09:49:20
(10) [1] [Jan 04 09:49:20:845] startmessage start opsi service connection: 04.01.2017 09:49:20
(11) [1] [Jan 04 09:49:20:845] startmessage: opsidata initialized: 04.01.2017 09:49:20
(12) [1] [Jan 04 09:49:20:845] startmessage create log: 04.01.2017 09:49:20
(13) [6] [Jan 04 09:49:23:238] JSON Bench for getDepotId "params":["vm-opsitest1.amf.local"],"id":1} Start: 09:49:20:846 Time: 00:00:02:392
(14) [6] [Jan 04 09:49:23:453] Starting sorting POC
(15) [6] [Jan 04 09:49:23:455] JSON service request https://192.1.2.5:4447/rpc getProductOrdering
(16) [6] [Jan 04 09:49:24:294] JSON Bench for getProductOrdering "params":["srv-opsi.amf.local"],"id":1} Start: 09:49:23:454 Time: 00:00:00:840
(17) [6] [Jan 04 09:49:24:474] JSON service request https://192.1.2.5:4447/rpc productOnClient_getObjects
(18) [6] [Jan 04 09:49:24:548] JSON Bench for productOnClient_getObjects "params":["",{"clientId":"vm-opsitest1.amf.local", Start: 09:49:24:472 Time: 00:00:00:076
(19) [6] [Jan 04 09:49:24:822] Finished sorting POC
(20) [5] [Jan 04 09:49:24:823] Computername:vm-opsitest1.amf.local
(21) [5] [Jan 04 09:49:24:823] Computername according to Environment Variable :VM-OPSITEST1
(22) [5] [Jan 04 09:49:24:823] opsi service URL https://192.1.2.5:4447
(23) [5] [Jan 04 09:49:24:823] Depot path: p:\
(24) [5] [Jan 04 09:49:24:823]
(25) [5] [Jan 04 09:49:24:848] bootmode BKSTD
(26) [5] [Jan 04 09:49:24:848] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(27) [5] [Jan 04 09:49:24:848] Resolved sequence of products (04.01.2017 09:49:24):
(28) [5] [Jan 04 09:49:24:848] Product 4 test : setup
(29) [5] [Jan 04 09:49:24:848] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(30) [6] [Jan 04 09:49:24:850] JSON service request https://192.1.2.5:4447/rpc getProduct_hash
(31) [6] [Jan 04 09:49:24:994] JSON Bench for getProduct_hash "params":["test","srv-opsi.amf.local"],"id":1} Start: 09:49:24:848 Time: 00:00:00:146
(32) [6] [Jan 04 09:49:25:241] JSON service request https://192.1.2.5:4447/rpc productOnClient_getObjects
(33) [6] [Jan 04 09:49:25:339] JSON Bench for productOnClient_getObjects "params":["",{"clientId":"vm-opsitest1.amf.local", Start: 09:49:25:240 Time: 00:00:00:099
(34) [6] [Jan 04 09:49:25:573] Actionrequest for product: test is (original/actual): (setup / setup)
(35) [6] [Jan 04 09:49:25:982] [test] Actionrequest for Product: test is: setup
(36) [6] [Jan 04 09:49:25:985] [test] JSON service request https://192.1.2.5:4447/rpc getProductProperties_hash
(37) [6] [Jan 04 09:49:26:222] [test] JSON Bench for getProductProperties_hash "params":["test","vm-opsitest1.amf.local"],"id":1} Start: 09:49:25:984 Time: 00:00:00:238
(38) [6] [Jan 04 09:49:26:444] [test] JSON service request https://192.1.2.5:4447/rpc getProduct_hash
(39) [6] [Jan 04 09:49:26:596] [test] JSON Bench for getProduct_hash "params":["test","srv-opsi.amf.local"],"id":1} Start: 09:49:26:443 Time: 00:00:00:153
(40) [6] [Jan 04 09:49:26:819] [test] JSON service request https://192.1.2.5:4447/rpc productOnClient_getObjects
(41) [6] [Jan 04 09:49:26:882] [test] JSON Bench for productOnClient_getObjects "params":["",{"clientId":"vm-opsitest1.amf.local", Start: 09:49:26:817 Time: 00:00:00:065
(42) [5] [Jan 04 09:49:27:108] [test] scriptname: "setup32.opsiscript", special path: "p:\test\"
(43) [6] [Jan 04 09:49:27:110] [test] JSON service request https://192.1.2.5:4447/rpc productOnClient_updateObject
(44) [6] [Jan 04 09:49:27:210] [test] JSON Bench for productOnClient_updateObject "params":[{"clientId":"vm-opsitest1.amf.local","ac Start: 09:49:27:109 Time: 00:00:00:101
(45) [1] [Jan 04 09:49:27:499] [test]
(46) [1] [Jan 04 09:49:27:499] [test] ============ Version 4.11.6.2 script "p:\test\setup32.opsiscript"
(47) [1] [Jan 04 09:49:27:499] [test] used script encoding: cp1252
(48) [1] [Jan 04 09:49:27:499] [test] used system encoding: cp1252
(49) [1] [Jan 04 09:49:27:499] [test] start: 2017-01-04 09:49:27
(50) [1] [Jan 04 09:49:27:499] [test] installing product: test_1.0-1
(51) [1] [Jan 04 09:49:27:499] [test] on client named "vm-opsitest1.amf.local"
(52) [1] [Jan 04 09:49:27:501] [test] loggedin user "Administrator"
(53) [1] [Jan 04 09:49:27:501] [test] opsi-script running as "SYSTEM"
(54) [1] [Jan 04 09:49:27:501] [test] opsi-script running with admin privileges
(55) [1] [Jan 04 09:49:27:501] [test] opsi-script running in standard script mode
(56) [1] [Jan 04 09:49:27:501] [test] executing: "C:\Program Files (x86)\opsi.org\opsi-client-agent\opsi-winst\winst32.exe"
(57) [1] [Jan 04 09:49:27:501] [test] system infos:
(58) [1] [Jan 04 09:49:27:511] [test] 00-0C-29-71-A5-E9 - PC hardware address
(59) [1] [Jan 04 09:49:27:511] [test] VM-OPSITEST1.AMF.local - IP name
(60) [1] [Jan 04 09:49:27:511] [test] 192.1.3.92 - IP address
(61) [1] [Jan 04 09:49:27:512] [test] DEU - System default locale
(62) [1] [Jan 04 09:49:27:512] [test] MS Windows 6.1 64 Bit, Edition: PRODUCT_PROFESSIONAL
(63) [1] [Jan 04 09:49:27:512] [test] opsi service version : 4
(64) [1] [Jan 04 09:49:27:512] [test]
(65) [6] [Jan 04 09:49:27:513] [test] Registry key [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion] opened
(66) [6] [Jan 04 09:49:27:513] [test] Key closed
(67) [6] [Jan 04 09:49:27:702] [test] opsi-script has version 4.11.6.2, required is : >= 4.11.4.6
(68) [5] [Jan 04 09:49:27:710] [test] ReportMessages was True is set to true
(69) [5] [Jan 04 09:49:27:711] [test] Set $LogDir$ = "c:\opsi.org\log"
(70) [6] [Jan 04 09:49:27:720] [test] The value of the variable "$LogDir$" is now: "c:\opsi.org\log"
(71) [5] [Jan 04 09:49:27:720] [test] Set $ProductId$ = "test"
(72) [6] [Jan 04 09:49:27:720] [test] The value of the variable "$ProductId$" is now: "test"
(73) [5] [Jan 04 09:49:27:720] [test] Set $MinimumSpace$ = "10 MB"
(74) [6] [Jan 04 09:49:27:720] [test] The value of the variable "$MinimumSpace$" is now: "10 MB"
(75) [5] [Jan 04 09:49:27:720] [test] Set $InstallDir$ = "C:\Program Files (x86)\test"
(76) [6] [Jan 04 09:49:27:720] [test] The value of the variable "$InstallDir$" is now: "C:\Program Files (x86)\test"
(77) [6] [Jan 04 09:49:27:720] [test] If
(78) [6] [Jan 04 09:49:27:721] [test] Free on Disk C:: 4.665.081.856 bytes This is more than the required amount of 10.000.000 bytes
(79) [5] [Jan 04 09:49:27:721] [test] HasMinimumSpace ("C:", $MinimumSpace$) <<< result true
(80) [5] [Jan 04 09:49:27:721] [test] not(HasMinimumSpace ("C:", $MinimumSpace$)) <<< result false
(81) [6] [Jan 04 09:49:27:721] [test] Then
(82) [6] [Jan 04 09:49:27:721] [test] Else
(83) [5] [Jan 04 09:49:27:721] [test] comment: Show product picture
(84) [5] [Jan 04 09:49:27:734] [test] message Installing test ...
(85) [5] [Jan 04 09:49:27:740] [test] comment: Start setup program
(86) [6] [Jan 04 09:49:27:741] [test] Changed current directory to p:\test
(87) [5] [Jan 04 09:49:27:765] [test]
(88) [5] [Jan 04 09:49:27:765] [test] Execution of Winbatch_install
(89) [6] [Jan 04 09:49:27:766] [test] Call ""p:\test\test.bat""
(90) [6] [Jan 04 09:49:27:766] [test] Waiting until the called process is finished
(91) [4] [Jan 04 09:49:27:766] [test] winbatch call of not executable file: p:\test\test.bat is deprecated
(92) [6] [Jan 04 09:49:28:615] [test] ExitCode 1 Executed process ""p:\test\test.bat""
(93) [6] [Jan 04 09:49:28:622] [test]
(94) [6] [Jan 04 09:49:28:622] [test] ~~~~~~~ Start Sub ~~~~~~~ Sub_check_exitcode
(95) [5] [Jan 04 09:49:28:625] [test] comment: Test for installation success via exit code
(96) [5] [Jan 04 09:49:28:625] [test] Set $ExitCode$ = getLastExitCode
(97) [6] [Jan 04 09:49:28:626] [test] The value of the variable "$ExitCode$" is now: "1"
(98) [6] [Jan 04 09:49:28:626] [test] If
(99) [5] [Jan 04 09:49:28:626] [test] $ExitCode$ = "0" <<< result false
(100) [5] [Jan 04 09:49:28:626] [test] ($ExitCode$ = "0") <<< result false
(101) [6] [Jan 04 09:49:28:626] [test] Then
(102) [6] [Jan 04 09:49:28:626] [test] Else
(103) [5] [Jan 04 09:49:28:626] [test] comment: Setup program gives a exitcode unequal zero: 1
(104) [6] [Jan 04 09:49:28:626] [test] If
(105) [5] [Jan 04 09:49:28:626] [test] $ExitCode$ = "1605" <<< result false
(106) [5] [Jan 04 09:49:28:626] [test] ($ExitCode$ = "1605") <<< result false
(107) [6] [Jan 04 09:49:28:626] [test] Then
(108) [6] [Jan 04 09:49:28:626] [test] Else
(109) [6] [Jan 04 09:49:28:626] [test] If
(110) [5] [Jan 04 09:49:28:627] [test] $ExitCode$ = "1641" <<< result false
(111) [5] [Jan 04 09:49:28:627] [test] ($ExitCode$ = "1641") <<< result false
(112) [6] [Jan 04 09:49:28:627] [test] Then
(113) [6] [Jan 04 09:49:28:627] [test] Else
(114) [6] [Jan 04 09:49:28:627] [test] If
(115) [5] [Jan 04 09:49:28:627] [test] $ExitCode$ = "3010" <<< result false
(116) [5] [Jan 04 09:49:28:627] [test] ($ExitCode$ = "3010") <<< result false
(117) [6] [Jan 04 09:49:28:627] [test] Then
(118) [6] [Jan 04 09:49:28:627] [test] Else
(119) [3] [Jan 04 09:49:28:627] [test] Error: Fatal: Setup program gives an unknown exitcode unequal zero: 1
(120) [5] [Jan 04 09:49:28:627] [test] Error level set to fatal
(121) [5] [Jan 04 09:49:28:627] [test] Process aborted
(122) [6] [Jan 04 09:49:28:627] [test]
(123) [6] [Jan 04 09:49:28:627] [test] ~~~~~~~ End Sub ~~~~~~~ Sub_check_exitcode
(124) [6] [Jan 04 09:49:28:627] [test]
(125) [5] [Jan 04 09:49:28:627] [test] Process aborted
(126) [1] [Jan 04 09:49:28:627] [test] ___________________
(127) [1] [Jan 04 09:49:28:627] [test] script finished
(128) [1] [Jan 04 09:49:28:628] [test] 1 error
(129) [1] [Jan 04 09:49:28:628] [test] 1 warning
(130) [1] [Jan 04 09:49:28:628] [test]
(131) [1] [Jan 04 09:49:28:628] [test] installed product: test Version: 1.0-1
(132) [1] [Jan 04 09:49:28:628] [test]
(133) [5] [Jan 04 09:49:28:629] [test] We do not look for a update script, because the setup script is failed
(134) [6] [Jan 04 09:49:28:630] [test] JSON service request https://192.1.2.5:4447/rpc productOnClient_updateObject
(135) [6] [Jan 04 09:49:28:703] [test] JSON Bench for productOnClient_updateObject "params":[{"clientId":"vm-opsitest1.amf.local","ac Start: 09:49:28:629 Time: 00:00:00:074
(136) [6] [Jan 04 09:49:28:930] Registry key [HKLM\SOFTWARE\opsi.org\winst] opened
(137) [6] [Jan 04 09:49:28:930] Variable "RebootRequested" is keeping its value "0"
(138) [6] [Jan 04 09:49:28:930] Variable "LastLogFilename" is keeping its value "c:\opsi.org\log\opsi-script.log"
(139) [6] [Jan 04 09:49:28:931] Variable "ContinueLogFile" is keeping its value "0"
(140) [6] [Jan 04 09:49:28:931] Variable "NumberOfErrors" is keeping its value "0"
(141) [6] [Jan 04 09:49:29:009] Key flushed
(142) [6] [Jan 04 09:49:29:009] Key closed
(143) [5] [Jan 04 09:49:29:026] -------- submitted part of log file ends here, see the rest of log file on client ----------
Re: Installations-Batch mit Domänen-Adminrechte ausführen
hi IvicaE,
Wir übergeben unsere Script - Inhalte immer an den entsprechenden Interpreter bzw die Windows - API, und wir geben auch die erhaltenen Fehlercodes weiter.
'WinBatch' - Skripte werden via Windows API aufgerufen. Hier sollte anschießend mit dem Check_Exit_Code - Snippet geschaut werden, ob es Fehler gab, da ja einige Error-Codes durchaus positiv zu bewerten sind (3010) .
'DosInAnIcon' - Skripte werden direkt via cmd aufgerufen. Hier gibt es idR nur Exitcode 0 oder 1.
Wenn man also wissen will, in welcher Zeile er auf die Nase fällt, dann müsste man einzelne Sections dafür schreiben.
Zu den Berechtigungen im Netzwerk:
das opsi-script auf dem Client läuft mit dem User 'SYSTEM', wie auch im Log immer bemerkt wird.
Möglich wäre ggf, diesem User auf Client-PCs der Domäne lesenden Zugriff auf das gewünschte Share zu geben. Ich meine, das sollte klappen, wäre aber auch nochmal am Ergebnis interessiert
Wir übergeben unsere Script - Inhalte immer an den entsprechenden Interpreter bzw die Windows - API, und wir geben auch die erhaltenen Fehlercodes weiter.
'WinBatch' - Skripte werden via Windows API aufgerufen. Hier sollte anschießend mit dem Check_Exit_Code - Snippet geschaut werden, ob es Fehler gab, da ja einige Error-Codes durchaus positiv zu bewerten sind (3010) .
'DosInAnIcon' - Skripte werden direkt via cmd aufgerufen. Hier gibt es idR nur Exitcode 0 oder 1.
Wenn man also wissen will, in welcher Zeile er auf die Nase fällt, dann müsste man einzelne Sections dafür schreiben.
Zu den Berechtigungen im Netzwerk:
das opsi-script auf dem Client läuft mit dem User 'SYSTEM', wie auch im Log immer bemerkt wird.
Möglich wäre ggf, diesem User auf Client-PCs der Domäne lesenden Zugriff auf das gewünschte Share zu geben. Ich meine, das sollte klappen, wäre aber auch nochmal am Ergebnis interessiert
---
hoping to help
if your problem was solved, pls mark this thread as 'SOLVED'. thank you .
-- no PN support --
Andre
hoping to help
if your problem was solved, pls mark this thread as 'SOLVED'. thank you .
-- no PN support --
Andre
Re: Installations-Batch mit Domänen-Adminrechte ausführen
@ngbr
Ich habe die Freigabe soeben angeschaut und diese hat durchgehend (also bis in das letzte Unterverzeichnis und die Dateien selber) 'SYSTEM darf alles'-Berechtigung. Wenn Opsi nun mit 'SYSTEM'-Berechtigung arbeitet, dann sollte das doch klappen, richtig?
Ich habe die Freigabe soeben angeschaut und diese hat durchgehend (also bis in das letzte Unterverzeichnis und die Dateien selber) 'SYSTEM darf alles'-Berechtigung. Wenn Opsi nun mit 'SYSTEM'-Berechtigung arbeitet, dann sollte das doch klappen, richtig?
Re: Installations-Batch mit Domänen-Adminrechte ausführen
hi IvicaE,
naja ... nicht ganz. Dies sind die Rechte des lokalen SYSTEMs auf dem Server, wenn ich das richtig verstehe.
man muss explizit die Berechtigungen für alle (gewünschten) SYSTEM User der PCs im Netzwerk vergeben. SYSTEM ist immer ein lokaler Account.
http://serverfault.com/questions/411765 ... ain-networ
> 'ensure that you have 'Computers' selected' .. muss man extra auswählen iirc.
Wenn du eine deutsche Beschreibung bzw Lösung gefunden hast, gerne nochmal posten. ich kann es hier leider gerade nicht nachstellen ..
thx
naja ... nicht ganz. Dies sind die Rechte des lokalen SYSTEMs auf dem Server, wenn ich das richtig verstehe.
man muss explizit die Berechtigungen für alle (gewünschten) SYSTEM User der PCs im Netzwerk vergeben. SYSTEM ist immer ein lokaler Account.
http://serverfault.com/questions/411765 ... ain-networ
> 'ensure that you have 'Computers' selected' .. muss man extra auswählen iirc.
Wenn du eine deutsche Beschreibung bzw Lösung gefunden hast, gerne nochmal posten. ich kann es hier leider gerade nicht nachstellen ..
thx
---
hoping to help
if your problem was solved, pls mark this thread as 'SOLVED'. thank you .
-- no PN support --
Andre
hoping to help
if your problem was solved, pls mark this thread as 'SOLVED'. thank you .
-- no PN support --
Andre
-
uncle_scrooge
- Beiträge: 650
- Registriert: 21 Feb 2012, 12:03
- Wohnort: Mainz
Re: Installations-Batch mit Domänen-Adminrechte ausführen
Die einfachste Variante wäre, einen domain user anzulegen, und ihn ausschließlich für den fraglichen share und das dahinterliegende Dateisystem lesend zu berechtigen.
Und diesen Benutzer dann im Batch zu benutzen. Per net use am IPC$-share des Servers anmelden, oder direkt ein Laufwerk mappen.
Ist zwar einfach, aber in Hinblick auf Sicherheit nicht nur unschön, sondern eigentlich grob fahrlässig, da der Benutzer samt Passwort zumindest temporär auf dem lokalen Rechner bekannt ist.
Wenn ihr damit leben könnt.......
Die zweite Variante, die ngbr ausgegraben hat, ist durchaus ein gangbarer Weg. Gruppe anlegen, die entsprechenden computer objects in die Gruppe bringen, und die Gruppe entsprechend berechtigen.
Hat nur zwei Nachteile. Erstens müßt ihr bei der Zuweisung des ERP-Pakets immer daran denken, ist der Rechner von Lieschen Müller schon in der Gruppe?
Zweitens greifen Änderungen an den Gruppenzugehörigkeiten nicht (immer) sofort. Sondern brauchen eine Neuanmeldung, daß das zieht. Beim computer object heißt das Neustart.
Und diesen Benutzer dann im Batch zu benutzen. Per net use am IPC$-share des Servers anmelden, oder direkt ein Laufwerk mappen.
Ist zwar einfach, aber in Hinblick auf Sicherheit nicht nur unschön, sondern eigentlich grob fahrlässig, da der Benutzer samt Passwort zumindest temporär auf dem lokalen Rechner bekannt ist.
Wenn ihr damit leben könnt.......
Die zweite Variante, die ngbr ausgegraben hat, ist durchaus ein gangbarer Weg. Gruppe anlegen, die entsprechenden computer objects in die Gruppe bringen, und die Gruppe entsprechend berechtigen.
Hat nur zwei Nachteile. Erstens müßt ihr bei der Zuweisung des ERP-Pakets immer daran denken, ist der Rechner von Lieschen Müller schon in der Gruppe?
Zweitens greifen Änderungen an den Gruppenzugehörigkeiten nicht (immer) sofort. Sondern brauchen eine Neuanmeldung, daß das zieht. Beim computer object heißt das Neustart.