Sinoxy

Schau mal ob Dual-Scan aktiv ist: https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/

Aha. Und was funktioniert nicht gut? Wenn das Thema Bestandteil deines Projekts sein soll, sollte die Problematik dazu beschrieben werden. Ansonsten könntest du dich auf die Verteilung von Software und ggf. die Aktualisierung von Fachanwendungen beschränken. Nicht falsch verstehen, aber ich meinte dass die Formulierung hier etwas präzisiert werden müsste, denn: Dass Software Updates nicht zentral verteilt werden, jedoch ein vorhandener WSUS bereits in der Umgebung existiert, stellt ohne eine nähere Beschreibung schon ein gewissen widerspruch dar.

Projektbeschreibung: Projektumfeld: Würde ich etwas anders formulieren. Software Updates (BS ist auch eine Software) werden nicht zentral verteilt aber es existiert ein WSUS?

Wie wäre es wenn du statt Struct´s einfach Klassen verwendest. Die privaten Attribute änderst du dann per Setter.

Dein Projekt hat nur 34 Std?

Wenn jemand umzieht trägst Du zuerst die neue Adresse in die Relation Adressen ein. Diese neue Adresse bekommt dann eine neue ID, anschließend änderst Du das Attribut AdressID in der Relation Angestellten auf das neu erzeugte Tupel in Adressen. Ferner müsste PLZ und Ort als eigentständige Relation auftrauchen um auch hier Redundanzen zu vermeiden. Denn die PLZ ist vom Ort abhängig und nicht von AdressID. Die PLZ kann als Fremdschlüssel in die Relation Adressen aufgenommen werden.

Ja du kannst den DC trotzdem herunterstufen. Sollte dies nicht erfolgreich sein, kannst du ein forceremoval durchführen: "dcpromo /forceremoval" anschließend musst du dann noch ein metadata cleanup durchführen. Viel Erfolg

Der NetApp DSM ist doch uralt? Und wurde seit 2008 schon nicht mehr benötigt Windows MPIO Feature installieren und fertig :-)

Upgrade einer Exchange Version ist nicht möglich. Wie du schon herausgefunden hast, ist es notwendig beide Server paralell zu betreiben und die Postfächer zu migrieren. In-Place Upgrade des Betriebssystems von 2008 auf 2008 R2 würde ich auch nicht machen. Warum nicht gleich alles ordentlich? Bei solchen Sachen kann man nie genau sagen, was nachher funktioniert oder eben nicht Ich würde das ganze erstmal auf einzelen Hosts auseinanderziehen, sprich für AD, SQL, Warenwirtschaftssystem und Exchange eigene Server bereitstellen (bspw. auf einem Single Hyper-V Host) und anschließend die Daten migrieren.

Dann hättest du das mal dazuschreiben können! Sollen wir dir alles aus der Nase ziehen?! Bei 2007 ist "unknown Computer" support nicht integriert, es sei denn du hast Release 3 installiert?! Ansonsten musst du eine Assosiation mittels der MAC-Adresse für den Client erstellen: Computerverwaltung -> Betriebssystembereitstellung -> Computerzuordnung -> Computerinformationen importieren -> Einzelnen Computer importieren Anschließend muss Computername, MAC-Adresse eingebenen werden und danach die Ziel-Collection ausgewählt werden. Die Tasksequenz muss dann natürlich auf deine Ziel-Collection angekündigt werden. Log-Datei fürs Troubleshooting heißt: SMSPXE.LOG

Welche Fehlermeldung erhälst du denn? Welche Version ist im Einsatz? Bei 2012 musst du den DP für PXE aktivieren, anschließend DHCP Optionen setzten und verifizieren, dass die Boot-Images sich ebenfalls auf dem DP befinden. Bei 2007 musst die den PXE Service Point installieren und konfigurieren.

Wie sind die LUNs angebunden? Via iSCSI? Falls ja prüf die Einstellungen, dass diese nach Reboot wieder verbunden werden!

WSUS 4 ist nicht supported.

ISO Datei ist auf jeden Fall korrupt. Von welcher Quelle hast du die ISO bezogen?

Ist "Append to media, overwrite if no appendable media is available" konfiguriert?

System Center ;-)

Wie ist die denn die Konfiguration des WSUS Servers? Evtl. Fehlen Updates die nicht genehmigt oder nicht gedownloaded wurden...? Folgendes kannst Du auf dem Client noch testen: Stop the Automatic Updates service. Rename C:\Windows\SoftwareDistribution folder. Restart the Automatic Updates service. Go into Internet Explorer and delete the history, cookies, and temp internet files. Reboot then from a command prompt run wuauclt.exe /detectnow.

Suche auch die AP + Lösungen für FISI´s Würd mich freuen! :-) anhpnr@googlemail.com

Wie wärs mit MDT?

Ja das ist möglich. In einem Paket können sich mehrere Programme befinden, die nicht abhängig zu einander sind. Ankündigungen für die Programme können dann auf sog. Collection (Sammlungen von Computergruppen, die anhand von Parametern z.B. Modellnummer, OS, etc. erstellt werden können) gelegt werden (Versionierung also möglich - wird in der neuen Version noch verbessert). Da steh ich jetzt auf dem Schlauch...Wie meinst du das? Powershell erweiterungen? Oder das die Software, wenn sie Importiert mit dem richtigen Namen, Version, etc. automatisch eingepflegt werden? Wenn ja, ja ist möglich aber nur bei MSI Paketen, da werden die Informationen direkt ausgelesen.

SCCM ist keine Packagingsoftware, wie z.B. Wise! "Packete" im SCCM sind im Grundgenommen nur der Pfad wo die Daten liegen und das "Programm" ist die Komandozeile die ausgeführt werden soll. Die Betriebssystem, sowie Softwareinstallation (dazu müssen allerdings auch die passenden Silent Parameter mitgegeben werden) läuft automatisiert.

DC2 ist ebenfalls DHCP-Server? DHCP Server synchronisieren sich nicht - dieses Failover was du beschreibst ist möglich mit einem sog. Failover-Cluster (was allerdings etwas oversized für DHCP ist, wie ich finde) möglich. Eine andere möglichkeit wäre es, einfach 2 DHCP Server bereitzustellen, mit jeweils eigenem Adressbereich (beliebte Kombination z.B. 80 - 20). Was auch ginge: einen DHCP Server produktiv schalten und den anderen als "Standby" zu konfigurieren - heißt ohne Adressbereich. Anschließend per Skript die produktive DHCP Datenbank sichern und auf den anderen Server schieben und im Falle des Falles "zu schwenken", dies kann ebenfalls Skriptgesteuert sein (am besten über das Monitoring System) PS: In Windows Server 8 soll ein "echtes" DHCP Failover implementiert werden.

SCCM ohne AD wird nicht funktionieren. Das Schema des ADs muss sogar erweitert werden, um alle SCCM Funktionen nutzen zu können! SCCM ist ein ein klasse Produkt ist - jedoch nicht Projekttauglich - zu "Enterprise", evtl. als Teilprojekt. Auch die Patchverwaltung ist "Enterprise" heißt: von Microsoft hat vorgesehen, das ein Team die Patche vorher prüft und dann explizit für eine Ankündigung erstellt - automatische Genehmigungen gibt es nicht (wird in der nächsten Version geändert) - von daher würde ich, wenn das Unternehmen nicht so groß ist, den SCCM nicht für die Patchverwaltung einsetzten.

Leider kann ich die zwei Produkte nicht direkt vergleichen aber aus mehreren Quellen/Medien hört man, dass TrendMicro Nr.1 ist. Allerdings ist das Mangement von Forefront Endpoint Protection über den SCCM ein nettes Feature. In der 2012er Version wird es sogar nativ integriert.

Das passiert: In der OU "Buchhaltung-Lohn" mit deaktiverter Vererbung darf der Benutzer per GPO seinen Bildschirmschoner aktivieren.