roccomarcy

Moin, das Image zur Verteilung wurde aus einer ISO-Datei aus dem MSDN gebaut. Kein Sysprep, keine integrierte Updates oder Treiber. Das Image ist "frisch", wie du es ausgedrückt hast.

Guten Morgen, wir haben das Problem, dass nach einem Neustart die Anmeldung nicht erscheint. Stattdessen erhalten wir einen schwarzen Hintergrund mit einem blinkenden, blauen Kreisel. Es wurde schon vers. Hardware ausprobiert, überall der selbe Effekt. Die erste Anmeldung direkt nach der Installation geht ohne weiteres, nur nach einem Neustart tritt dieses Phänomen auf. Es handelt sich dabei um Windows 10 Pro (Build 1803), ob UEFI oder BIOS spielt keine Rolle. Es wird automatisiert via DeskCenter ausgerollt. Wir haben schon alle Einstellungen heruntergedreht, die Treiber getauscht, ohne Treiber installieren lassen, kein Erfolg. Hat evtl. von euch den selben Effekt? 1709 konnten wir ohne Probleme über die Mechanismen von DeskCenter verteilen. Der DC-Support zu dem Thema ist ruhig, schiebt es auf ein Problem mit 1803 und nicht DeskCenter. (DeskCenter nutzt die standardisierten Mechanismen von Microsoft). Gruß

Hallo, ich muss in nächster Zeit einige alte Systeme austauschen. Diese liefen aktuell unter Windows 7 Pro (aus einer SB-Version). Auf der neuen Hardware soll nun auch Windows 10 zum Einsatz kommen, doch durch diesen Dschungel an Lizenzen steige ich nicht mehr durch. Eigentlich war es der Plan auf eine Enterprise zu setzen, um die Möglichkeit zu haben die nicht mehr benötigten Features zu deaktivieren. Aus Kostengründen wird das aber definitv nicht mehr passieren. Nun musste ich leider erfahren das eine Windows 10 Pro Open-NL auch nur als Upgrade verfügbar ist und ich somit für die korrekte Lizenzierung eines neuen PCs eine Basislizenz Windows 10 + das Upgrade auf Open-NL kaufen muss, ähnlich wie mit der Enterprise, nur nicht so teuer. Ist das wirklich der korrekte Weg um an Windows 10 Pro Open-NL zu kommen und sich das Deployment einfacher zu machen? Die Windows 7 Lizenzen kleben physikalisch auf den alten Arbeitsplätzen und sind somit (mMn) nicht Upgrade-berechtigt. Gruß

Dient erstmal nur um eine Übergangslösung für 6 - 12 Monate und einer darauffolgenden Migration.

Guten Morgen, ggf. müssen wir ein Tochterunternehmen via Domänen-Trust an unsere Domäne anbinden. Die Mitarbeiter der Domäne sollen dann via Outlook auf unseren Exchange-Server zugreifen, da es in derer Domäne keinen gibt. Ist das Vorhaben über einen Trust zu Lösen das mittel der Wahl? Und man könnte in der Verwaltungskonsole vom Exchange dann auch auf die Benutzer der anderen Domäne zugreifen?

Vor der Anmeldung: 5 - 7 Minuten Nach der Anmeldung: 5 - 10 Minuten Windows Server 2008 R2 Domain Controller, Windows 7 Client, Windows Server 2012 als Fileserver. lokale Profile mit Ordnerumleitung. Und ja, war schon mal schneller.

Hallo, wir haben das Problem, dass die Rechner ziemlich lange vor und nach der Anmeldung warten müssen. Bei der Recherche im Internet bin ich auf die "Fast Logon Optimization" gestoßen von Microsoft. Leider werde ich nicht so richtig schlau aus den Beschreibungen - wir haben reine Windows 7 Clients im Einsatz, nutzen servergespeicherte Profile/Ordnerumleitungen und ich habe auf die Computer-Objekte (aus der Vergangenheit) folgende GPOs verlinkt: Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten -> AKTIVIERT Anmeldeskripts gleichzeitig ausführen -> AKTIVIERT Wenn ich es richtig verstanden habe ist die "Fast Logon Optimization" durch das aktivieren der ersten GPO deaktiviert, korrekt?

Vielen Dank, manchmal bedarf es einfach nur einen Denkstoß.

Windows 7-Systeme. Der Benutzer wird in einer Software-Verteilungssoftware hinterlegt, welche mit den Credentials die Installation durchführt. Agentless. Der Hersteller kann leider nicht helfen, da kommt die Aussage "einfach bei Dom-Admins, das funktioniert".

Hallo, was habe ich für Möglichkeiten in einer AD-Umgebung einen dedizierten Benutzer einzurichten, der die Möglichkeit hat, auf entfernten Systemen Software zu installieren? Ich hatte bis jetzt den Benutzer in die Gruppe "Domänen-Administratoren" hinzugefügt, das funktionierte auch soweit. Ich möchte Ihm jetzt aber die Gruppe entnehmen, da er die Berechtigungen eines Dom-Admins nicht haben soll. Gruß

Hallo, ich habe das Problem, dass ich mit PSExec keine Verbindung auf andere Arbeitsplätze in der Domäne aufbauen kann. Dabei spielt es keine Rolle, ob ich die Verbindung in einer admistrativen CMD herstellen möchte, oder über die Schalter -u und -p. Ich habe auch schon div. Versionen von PSExec durchprobiert, ohne Erfolg. Was zum Erfolg führt ist, wenn ich auf dem Ziel die Firewall deaktiviere - das kann aber nicht Ziel der Übung sein. Ich habe dann die Firewall-Regeln überprüft und mit div. Einträgen aus Google verglichen - alle freigegeben. Das Aktivieren der Logdatei gab auch keine weiteren Erkenntnisse, außer das Verbindung auf Port 51XXXX gedroppt werden. Die Ports ändern sich dynamisch. Auffällig ist, dass bei aktivierter Firewall die Verbindung über die IP-Adresse funktioniert! Nur über den Hostnamen selbst geht es nicht, es spielt dabei auch keine Rolle ob FQDN oder Hostname. Den Virenscanner habe ich schon deinstalliert, auf die ADMIN$-Freigabe kann ich mich auch verbinden, das sieht von den Vorraussetzungen her passend aus, aber ich habe leider keine Idee mehr. Ihr?

Wie meinst du das?

Guten Morgen, ich habe ein abgewandeltes Skript aus dem Technet gefunden, welches mir Netzwerkdrucker, die auf dem Server nicht mehr verfügbar sind, anzeigt. Ich würde diese Drucker auch gern automatisch lösen, leider komme ich mit dem Skript nicht weiter. Kann mir jemand ggf. Hilfestellung geben oder einen nötigen Hinweis, wie ich das Skript modifizieren muss? #requires -Version 2.0 Function Test-OSCPrinter { Try { Get-WmiObject -Class Win32_Printer -ErrorAction Stop | Where {$_.Network} | Select-Object Name, @{Name="Verbindungsstatus";Expression={$PrinterName = $_.Name; Try { $NetworkObj = New-Object -ComObject WScript.Network $NetworkObj.AddWindowsPrinterConnection("$PrinterName") "Verbunden" } Catch {"Nicht verbunden"}}} } Catch { Write-Warning "Fehler, läuft der Spooler-Dienst?" } } Test-OSCPrinter Die Ausgabe des Skript ist wie folgt: Gruß

Ich grätsch hier mal rein - warum siehst du das so?

Tach, siehe erster Post - dort ist das Skript beschrieben. Die Fehlermeldung kommt jedoch von dem Cisco-Gerät, nicht plink.

Guten Morgen, ich würde gerne via SSH und pLink automatisiert Befehle auf einem Cisco-Gerät absetzen. Ich bin leider kein Cisco-Spezialist, leider erhalte ich daher beim Ausführen der Befehlsdatei folgenden Fehler: Line has invalid autocommand "enable Der Benutzer hat das Privilege Level 15, folgende Befehle sollen ausgeführt werden: enable configure terminal interface dot11Radio 0 shutdown end write exit

Und wenn ich das über eine Batchdatei heraus ausführe?

Ah, da bekomme ich eine Sicherheitswarnung. Darauf bin ich natürlich nicht gekommen. Danke für den Tip. Was wäre denn jetzt der beste Weg um dieses zu umgehen? Per Batchdatei ausführen?

Das Ergebnis wovon? Es gibt keine Ausgabe auf die Konsole, das Programm schreibt in die Ereignisanzeige, dort ist auch ein Eintrag zu finden (bei manueller Ausführung).

Hallo, ich hab es so ausgeführt, wie von dir beschrieben. Es wurde über die Konsole ausgeführt, nicht über einen Rechtsklick. Die Executionpolicys habe ich auch nicht verändert.

Guten Morgen, ich habe hier eine Umgebung, bestehend aus mehreren Windows 2008 R2 und Server 2012 R2 Domänen-Controllern, sowie reinen Windows 7 Pro Clients. Für eine Applikation muss in einem lokalen Drucker eine Einstellung geändert werden, was sich unter anderem durch WMI lösen lässt. Dazu habe ich ein Skript in PowerShell entwickelt, welches Lokal die Option des Druckers anpasst. Es werden keine Dateien auf irgendwelche Netzwerkfreigaben geschrieben, es läuft rein lokal. Kommen wir zum eigentlichen Problem. Führe ich das Skript lokal auf den Arbeitsplätzen aus, so läuft es ohne Probleme. Nun habe ich das Skript als "Starten"-Skript eingebunden und auf eine Reihe Testcomputer verlinkt. Leider wird das Skript nicht ausgeführt und in der Ereignisanzeige steht auch nichts interessantes. Was könnte es für Hintergründe haben? Ich habe erst an mangelnde Berechtigung gedacht, habe daher das Skript lokal mit "SYSTEM"-Berechtigung ausgeführt (dank PSExec), aber damit hat es auch funktioniert. In der Vergangenheit habe ich bereits "Auf Netzwerk warten" in den GPOs aktiviert. Edit1: Das Skript wurde unter dem Reiter "PowerShell" angelegt, es wird direkt aufgerufen, also nicht über eine BAT oder ähnliches.

Stimmt, wenn man sich eine Zeitlang mit den ganzen Cmdlets und Ausgaben beschäftigt hat, sieht man irgendwann das wesentliche nicht mehr. Macht natürlich für intern überhaupt keinen Sinn, wenn die AuthMethode hier nur auf Basic steht, kein Wunder das es da zu Abfragen kommen (kann). Danke für den Link. Das ist zu 100% ein Versehen, auch wenn ich bis vorhin noch nicht wusste, wofür dieser Eintrag überhaupt gut ist. Wie verhält sich diese Einstellung, wenn man mehrere Sites im AD hat? Sollte ich hier alle Sites, für die der eine CAS-Server zuständig ist, hinterlegen?

Hallo, SplitDNS auf die OWA-URL oder die AutoDiscover-URLs? Wenn ich die OWA-URL im DNS via SplitDNS konfiguriere, muss ich das externe Zertifikat ja noch intern hinterlegen, oder? Das Zertifikat ist ein Wildcard-Zertifikat für die Domäne, ist aber Valid, also nicht selbstsigniert. Welche restlichen URLs benötigst du noch?

Guten Morgen, ich habe hier seit einer Woche das Problem, dass eine Vielzahl an Anwendern sich beschwert, dass Sie beim Start von Outlook Ihr Kennwort eingeben müssen. Bei einigen Anwendern reicht die einmalige Eingabe, bei anderen scheint Outlook das Passwort nicht zu akzeptieren. E-Mails werden im Hintergrund trotzdem zugestellt - es scheint also irgendeine andere Schnittstelle Probleme zu machen (OAB?). Das Patchlevel der Outlook Installationen ist auf allen Systemen gleich (SP2 + Updates). Exchange ist auch soweit durchgepatched. Die einzige Änderung, die stattgefunden hat, war die Einrichtung eines A-Records für autodiscover von einer E-Maildomäne inkl. Aktivierung der AutoDiscover-Regel auf dem Proxy. Die Probleme finden jedoch bei Anwendern mit anderen E-Maildomänen statt. Das merkwürdige ist auch, dass es einige Systeme gibt, die einfach gar keine Probleme haben, bei gleicher Outlook-Konfiguration. Hätte hier vielleicht jemand einen Tip für mich? Ich hab die Autokonfiguration via Outlook auch an den Clients getestet, die sieht gut aus und wirft keine Fehler. $ Get-OutlookAnywhere | fl ExternalHostname: mail.DOMAIN.de ClientAuth: NTLM IISAuth: (Basic) $ Get-ClientAccessServer | fl OutlookAnywhereEnabled: true AutoDiscoverServiceInternalUri: https://mail.DOMAIN.de/Autodiscover/Autodiscover.xml AutoDiscoverSiteScope: mobile $ Get-ActiveSyncVirtualDirectory | fl ActiveSyncServer: https://mail.DOMAIN.com/Microsoft-Server-ActiveSync InternalUrl: https://srvexchange.domäne.local/Microsoft-Server-ActiveSync ExternalUrl: https://mail.DOMAIN.de/Microsoft-Server-ActiveSync $ Get-AutodiscoverVirtualDirectory | fl InternalAuthMeth: Basic, Ntlm, WindowsIntegrated, WSS ExternalAuthMeth: Basic, Ntlm, WindowsIntegrated, WSS InternalUrl: leer ExternalUrl: https://mail.DOMAIN.de/Autodiscover/Autodiscover.xml $ Get-OabVirtualDirectory | fl InternalUrl: https://srvexchange.domäne.local/OAB ExternalUrl: https://mail.DOMAIN.de/OAB InternalAuth: WindowsIntegrated ExternalAuth: WindowsIntegrated

LoadBalancer von KEMP leider nicht, aber ReverseProxy und andere Strukturen sind vorhanden. Ist das denn auch der Best Practice-Way?