monstermania

@Dirk-HH-83
Hallo Namensvetter,
ich hatte vor einigen Jahren mal hier ein entsprechendes Tool vorgestellt (Freeware):
Wir nutzen das Tool immer noch. Funktioniert auch problemlos auf Windows 2019 Server.
 
Gruß
Dirk
 

Wir nutzen m.W. nach VMWare 6.7. Ist aber nicht meine Baustelle da für die VMWare-Umgebung andere Kollegen zuständig sind.
Wir sind aber immer ziemlich aktuell was SW-Updates angeht. 
 
Wenn laut 'smsts.log' Deine Tasksequenz komplett (und fehlerfrei!?) durchläuft es aber trotzdem nicht funktioniert stimmt wohl etwas mit Deiner TS nicht! 
Wir installieren hier auch Windows 10 per TS komplett mit Domain-Join usw. Und falls ein Domain-Join fehlschlägt, bricht die TS natürlich ab weil wir innerhalb der TS prüfen, ob der Domain-Join auch erfolgreich war!
 
Gruß
Dirk

Moin,
das Rätsel ist gelöst!
Microsoft hat zwischenzeitlich die Dokumentation zum WOL SCCM 'angepasst'. Die neue Methode des WOL ab SCCM 1810 funktioniert ausdrücklich nicht im Rahmen des SW-Deployments!
https://docs.microsoft.com/de-de/sccm/core/clients/deploy/configure-wake-on-lan
 
Vielen Dank auch MS und WTF soll so etwas!? Da brauchen die Jahre um endlich ein halbwegs funktionierendes WOL über Subnetzgrenzen hinweg in SCCM zu integrieren und dann ist das wieder nur halber Kram!
 
Gruß
Dirk

Moin,
wollte Euch mal über die Ursache und die Lösung informieren.
Ursache für das Verschwinden des Hintergrundbilds auf den Windows 10 Clients war die Nutzung von TeamViewerQS einer älteren Version (nachvollzogen mit V9) auf den jeweiligen Clients.
Wenn die Option 'Bildschirmhintergrund entfernen' im TeamViewer des Supporters aktiviert ist, wird nach dem nächsten Neustart des Clients der den TeamViewerQS genutzt hat das Hintergrundbild abgeschaltet und bleibt schwarz.
Ursache dafür ist, das TeamViewerQS die Windows Standardeinstellung für 'Wallpaper' aus 'HKEY_CURRENT_USER\Control Panel\Desktop' löscht.
 
Als Lösung setze ich jetzt per GPO die Wallpapereinstellung wieder auf den Windows-Standardwert: 'C:\WINDOWS\web\wallpaper\Windows\img0.jpg'
Und Voila. Bei allen Clients wird jetzt wieder der Firmendesktop angezeigt
 
Gruß
Dirk
 
 

Hab ich Alles schon durch!  :(
Hab über 2 Stunden vor der Kiste gehockt!
 
Schlussendlich hab ich die Kiste per Image neu installiert. Die komplette Einrichtung war dann auch in 2 Stunden durch.
Diesmal hat es mit dem Dymo-Drucker auch Alles problemlos geklappt.
Ich liebe Windows!  :confused:

Moin,
dank des hier genannten Tools von Kyocera konnte ich das Problem schlussendlich lösen: http://www.mcseboard.de/topic/163811-drucker-treiber-restlos-entfernen/?p=1008176
 
Gruß
Dirk

@all
Danke
 
Nein, PS ist keine Option (zumindest noch nicht :rolleyes: ).
 
Kurz zur Erklärung was das Script macht bzw. machen soll.
Ein Prüfstand erzeugt Protokolle (Diagramm als PDF- und Messwerte als CSV-Dateien). Diese werden vom Prüfstand automatisch in einem Ordner abgelegt.
Aufgabe ist, für jedes Protokoll ein Formular (PDF) zu erzeugen, was an den Kunden geschickt wird. Dazu wird eine Word-Fomularvorlage mit den Werten aus der CSV-Datei und einem ERP-System (SQL-db) verknüpft/gefüllt und als Endabnahmeprotokoll als PDF gespeichert bzw. gedruckt.
 
Mein eigentliches Problem war ja schlichtweg die Anzahl der CSV-Dateien im Ordner. Jeder Durchlauf des Scripts durch den Ordner braucht(e) mehr als 10 Minuten und dann kam im schlimmsten Fall gar nichts heraus, weil seit dem letzten Durchlauf gar keine neuen Prüfstandtests gemacht wurden! Und außerdem hat es immer mindestens die Zeit gebraucht, bis wieder ein Durchlauf gestartet werden kann...
 
Eine "Lösung" für mein Problem zu finden war recht einfach. Ein simples 'xcopy quelle ziel /d:mm-dd-yyyy /y' im Script kopiert alle csv-Dateien => dem aktuellen Datum in ein Importverzeichnis. Das sind dann nur wenige Dateien am Tag.
Darauf läuft dann erste meine VBS-Programmierung los.
Da die verarbeiteten CSV-Dateien anschließend eh in einer Datenbank erfasst werden, ist es kein Problem die bereits beim letzten Durchlauf verarbeiteten CSV-Dateien aus dem Importordner zu löschen, ohne das ein Endabnahmeprotokoll erzeugt wird.
Vielleicht nicht unbedingt die eleganteste Lösung, aber zumindest eine ohne viel Aufwand.  :D
Insgesamt braucht das Script jetzt nur ein paar Sekunden... 

Danke, hab ich mir schon fast gedacht  :( .
Na ja, evtl kaufen wir uns einfach nochmal 4 PKC gebraucht dazu damit es wieder passt!

Wurde ja nun schon unzählige Male hier behandelt :rolleyes:
Hier findest Du eine Schritt für Schritt Anleitung zur Einrichtung des Split DNS:
https://www.psw-group.de/newsletter/splitDNS.pdf

Moin,
hier nochmal der Hintergrund zum Problem mit den eckigen Klammern im Betreff/Mailbody und Exchange-Transportregeln.
https://social.technet.microsoft.com/Forums/en-US/31981040-902e-4cd2-9941-961c93eb70a4/transport-rules-when-subject-contains-certain-words-or-text-pattern-matching?forum=exchangesvrsecuremessaginglegacy
Bis Exchange 2007 SP1 hat das mit den eckigen Klammern auch mit den Exchange-Transportregeln funktioniert. Deckt sich auch mit meinen Erfahrungen, da ich noch wusste, dass ich das schon mal genutzt hatte :)  
 
Hier die Doku zu den Möglichkeiten von RegEx in den Transportregeln von Exchange 2010:
https://technet.microsoft.com/de-de/library/aa997187(v=exchg.141).aspx
Eckige Klammern sind hier leider kein Thema... :cry:
 
Gemäß der Doku habe ich das Tagging vom AV/SPAM Gateway mal auf runde Klammern umgestellt '(BULK)' bzw. '(PROBABLY_SPAM)'. In der Transportregel wird dass dann als '\(BULK\)' eingegeben (Natürlich ohne die Hochkommas!)
So funktioniert dass dann auch mit dem Taggen von geklammerten Begriffen im Betreff/Mailbody und Exchange Transportregeln.
Trotzdem schade, dass MS sich nicht an den allgemeingültigen Standard in Sachen RegEx hält.
 
Gruß
Dirk

@All
Danke für die Hinweise bezüglich des Einsatzes eines Reverse-Proxy's. Wir setzten eine Securepoint UTM ein, die ebenfalls die Möglichkeit für einen Reverse-Proxy bietet. Das Thema werde ich demnächst mal gemeinsam mit unserem FW Dienstleister angehen.
 
Hier nun eine Lösungsmöglichkeit direkt über den Exchange bzw. den IIS um OWA nur im internen Netzt verfügbar zu machen.
1. Auf dem Server der OWA bereitstellt die IIS Rolle "IP- und Domäneneinschränkungen" installieren
2. IIS-Manager starten und das VZ OWA aufrufen
3. In den Features zu OWA den punkt "Einschränkungen für IP-Adressen und Domänen" auswählen
4. Nun in den Aktionen den Punkt "Zulassungseintrag hinzufügen..." auswählen. Hier nun alle gewünschten Netzwerke hinzufügen, die weiterhin zugriff auf OWA haben sollen (Zulassen).
5. Damit die obigen Einstellungen greifen, unter Aktionen den Punkt "Featureeinstellungen bearbeiten..." auswählen. Hier die Option für "Zugriff für nicht angegebene Clients:" auf "Verweigern" umstellen.
 
Nun können nur noch Clients, die aus den definierten IP-Ausnahme-Bereichen kommen auf OWA zugreifen.
 
Gruß
Dirk
 

Moin,
ich komme hier nicht mehr weiter mit der Dateisuche auf unserem Windows 2012 Fileserver.
1. Ich auf den entsprechenden Ordnern dem 'SYSTEM' Vollzugriff erteilt (durchvererbt auf Ordner und Dateien).
2. Dateisuche nach 'pdf' ohne Indexierung der betroffenen Order/Dateien -> Es werden insgesamt 613 PDF-Dateien gefunden, was auch richtig ist. Die Suche dauert natürlich einige Sekunden, da zunächst alle Unterordner durchsucht werden müssen
3. Anschließend habe ich die betroffenen Ordner in die Indexierung aufgenommen. Nach Ende des Indexierungsdurchlaufs suche ich wieder in den Ordnern nach 'pdf' und erhalte jetzt nur 11 Treffer! 
 
Die Treffer liegen in unterschiedlichen Jahresordnern. Alle PDF-Dateien haben die gleichen Zugriffsrechte und den gleichen Besitzer.
In den Logs findet sich kein Fehler, der auf irgendwelche Probleme mit dem Indexdienst hindeutet.
 
Hat jemand einen Idee, warum die Indexierung nicht alle Dateien auflistet?
 
Gruß
Dirk
 
Ergänzung:
Ich habe gerade festgestellt, dass alle Dateien die im Suchindex indexiert wurden, das Dateiattribut 'A - Archive' besitzen.
Alle Dateien, die nicht Indexiert wurden haben die folgenden Dateiattribute:
A - Archive
P - Sparse File
L - Symbolic link/Junction
 
Das gleiche Problem tritt im Übrigen auch bei z.B. 'doc'- oder 'xls'-Dateien auf. Hat also nichts mit dem Dateityp zu tun.
 
Habe dann mal einfach den gesamten Ordnerpfad mit allen Dateien auf unsere QNAP kopiert. Anschließend habe ich dann den Ordnerpfad auf dem QNAP in 'TEST' umbenannt und wieder auf den Windows 2012 Server in das gleiche VZ zurück kopiert in dem auch das Original-VZ liegt. Die im kopierten Ordner enthaltenen Dateien haben jetzt alle nur noch das Attribut 'A - Archive'.
Nach einigen Sekunden war die Indexierung den 'neuen' Ordners angeschlossen.
Wenn ich jetzt in der kopierten Struktur nach 'pdf' werden sofort die 613 Treffer angezeigt!
 
Ganz offensichtlich werden die Dateien im Originalpfad nicht indexiert, da Sie die 'falschen' Attribute 'PL' haben...
Ich habe jetzt noch mal in der Datensicherung des alten 2003 Servers geschaut. Dort haben die entsprechenden Dateien auch nur das Attribut 'A'.
Kann das Verhalten des Indexdienstes evtl. mit der aktivierten Deduplikation auf dem neuen Windows 2012 Server zu tun haben?
Der Dienst Windows-Search wurde definitiv erst nach der Aktivierung der Deduplikation auf dem Server 2012 installiert und eingerichtet!
 
Ergänzung 2:
Offenbar gibt es da in der Tat ein Problem mit der Windows Search und Deduplikation!
Hier der entsprechende Fred im TechNet dazu:
https://social.technet.microsoft.com/Forums/en-US/d8c9c5b1-fc38-476d-a780-e14910edcf6f/widows-search-not-working-with-data-deduplication
 
 
Ich könnte manchmal echt kotzen!!! :mad:

Aua Aua... :cry:
Wenn Du nur einen 2012'er Server als Memberserver in die SBS Domäne aufnehmen willst brauchst Du keine Schemaerweiterung.
Willst Du aber den 2012'er als zusätzlichen DC in der SBS Domäne betreiben muss natürlich auch das Schema erweitert werden.
 
Das Problem bei Deinem konstrukt wird der der Lizenzserver für den RDP-Server werden. Dieser muss auch auf einem 2012 laufen. Aus Sicherheitsgründen sollte man die RDP-Lizenzdienste nicht auf einem RDP-Server installieren.
Von daher wäre es am besten gleich 2 x 2012 Server zu nehmen. 1 als zusätzlichen DC mit den RDP-Lizenzdiensten und 1 als reinen RDP-Server.