Roi Danton

Ein richtig gutes Tool um zu sehen was auf dem Client so passiert ist dies hier: https://github.com/rzander/sccmclictr Das SCCM Client Center zeigt z.B. die aktuellen Ankündigungen auf dem Client. Das ist sonst sehr mühselig aus den Logs zu lesen. Dort kann man diese auch einfach neustarten. Alles auch remote wenn WINRM läuft.

Moin Falconbase, das kann viele Ursachen haben. Ist das Paket überhaupt auf dem DP angekommen? Ist der DP und der Client in der gleichen Boundary? Was wurde beim Paket eingestellt (z.b. DP Groups usw. :) Ist remote schwer zu sagen. Aber SCCM ist ja der Server der milliardenlogfiles so sollte sich irgendwo, entweder auf dem Server, DP oder Client ein Log finden in dem geschrieben steht was passiert oder auch nicht. Bei genaueren Problemen versuche ich gern zu helfen ;) Gruß, Roi

Die DPs reichen für die Verteilung. Die WSUS Rolle wird nur auf dem SiteServer benötigt. Die WSUS updates werden quasi in Pakete umgebaut und dann über die normalen SCCM Methoden verteilt. Im Außenstandort wird erstmal nichts benötigt, solange Deine WAN Verbindung gut genug ist. Solltest Du vorhaben im Außenstandort OS-Verteilung zu betreiben benötigst Du einen DHCP-RelayAgent, der z.B. auf einem Router laufen kann. Möchtest Du Bandbreite einsparen (was eigentlich immer der Fall ist) benötigst Du dort einen DP. Dieser kann auch auf einem Windows 10 installiert werden. Wenn Du auch die komplette OS-Verteilung dort vornehmen möchtest dann muss es ein Server sein, damit die PXE-Rolle über SCCM aktiviert werden kann. Ist auf einem Client bereits ein OS installiert auf dem der SCCM-Agent installiert werden kann, kann das System auch ohne Netzwerkboot installiert werden. Habe ich schon für kleinere Standorte gemacht, wo tasächlich nur einer oder zwei vor Ort waren. War das anbooten des Systems nicht mehr möglich musste eh der Paketdienst bemüht werden. Dann den DP dort nur auf einem Windows 10 mit genug Platz und gut ist ;) Ich finde SCCM da sehr flexiebel. Man muss sich halt jeden Standort anschauen und überlegen was man da tatsächlich machen möchte.

Wir reden schon von der aktuellen Version des SCCM. Sicher muss man einmal manuell sagen was ich wo deployen möchte. Das muss man am WSUS auch. Nur hat man beim SCCM deutlich mehr möglichkeiten. Wenn man einmal festgelegt hat welche Updates Automatisch verteilt werden sollen passiert das auch genau so. Vielleicht solltest Du Deine Meinung mal auf einen aktellen Stand bringen. Wem soll es helfen soetwas zu posten?

Moin Du, es gibt da viele Gründe, die dafür sprechen alles im SCCM zu halten. Erstmal von der praktischen Seite, Du hast eine Console für alles. Dann hast Du nur eine Komponente die auf Deinem Client Software installiert. Es kann zu Problmen kommen wenn Dein SCCM versucht Software zu installieren jedoch Zeitgleich Dein Windowsupdate dabei ist irgendwelche Patche zu installieren. Dann ist das Reporting beim SCCM deutlich besser als "nur" WSUS. Die Planbarkeit der Installation ist beim SCCM ebenfalls deutlich besser. Wartungsfenster etc. Generell ist es für den Nutzer besser erkennbar was passiert mit dem SCCM Client. Weiterhin kann man die Updates gleich in sein OS-Deployment integieren ggf. Offline Images, falls nötig. Der SCCM hat umfangreichere Möglichkeiten Updates automatisch bereit zu stellen, Dynamische Client Gruppen. Halt auch alles was Ihn generell für Softwareverteilung interssant macht. Ich würde persöhnlich nicht mit einem sparaten WSUS arbeiten. Ich hoffe ich konnte Dir weiterhelfen. Gruß, Roi

Hi Nicolov, generell ist es natürlich möglich Skripte zu schreiben die all Deine Rechner abklappern und Seriennummern einsammeln, solange diese vorhanden sind. Es ist nicht generell so, dass jedes Gerät seine Seriennummer irgendwie dem Windows System verfügbar macht. Eigentlich macht das fast keine Hardware. Mainboards und USB-Massenspeicher sind da die Ausnahmen. Wenn Du die Seriennummer nicht im Gerätemanager findest, wird das Gerät auch keine liefern. Hier mal ein Beispiel wie man an Seriennummern von Laufwerken kommt: ForEach ($Device in $Devices){ gwmi win32_volume | Select-Object DriveLetter,SerialNumber } Die Seriennummer vom BIOS ist z.B. so zu bekommen: gwmi win32_bios | fl SerialNumber Dafür müssen aber wie gesagt die Geräte die SN liefern und Du musst wissen wo diese Informationen sind. Eventuell kannst Du mit dem WMI-Explorer suchen wo Du die SN findest. https://github.com/vinaypamnani/wmie2/releases Die Beispielskripte sind recht einfach dann mit einer Schleife zu versehen und mit AD-Anbindung kann man dann auch Clients aus dem AD abfragen und dann entsprechende Seriennummern einsammeln. Einfacher geht das natürlich mit z.B. einem SCCM. Aber auch hier. Der SCCM kann nur Informationen sehen, die auch da sind ;) Ich hoffe ich konnte ein wenig helfen. Schönen Gruß,

Ich werde es in zukunft deutlicher machen. Ich dachte das könne man so verstehen.

ja, das wäre eine möglichket als workaround. Danke!

Hi Sunny, für den WSUS hatte ich diese Schritte bereits ausgeführt. Das hat nicht geholfen. Online kann der Server leider nicht nach Updates schauen. Er ist übrigens selbst sein eigener WSUS. Gruß, Roi

Ja, was kann man wohl erwarten wenn ich ein CU1 auf ein CU12 System installieren möchte?! Es hat sich nicht installieren lassen. bzw. Keine Instance zum updaten angezeigt.

Hi zusammen, ich weiß garnicht ob es gestattet ist hier Fragen zum Thema SQL 2017 zu stellen, da das Foren Topic dies ja nicht vermuten läst... Aber was soll es :) Ich habe ein ungewöhnliches Verhalten auf einem SQL Server was ich mir nicht erklären kann und leider finde ich auch so nichts im Netz dazu. Das Windows Update möchte auf dem SQL Server immer das CU1 installieren (KB4038634). Dies schlägt immer fehl mit der Meldung 0x800070643. Was ein recht allgemeiner Fehler ist. Schaue ich mit die Eigenschaften des Servers an, läuft der SQL Server in der Build 14.0.3045.24. Dies ist bereits das CU12 (https://support.microsoft.com/de-ch/help/4047329/sql-server-2017-build-versions) Das löschen des SoftwareDistributions Ordners hat den Server schon mal nicht davon abgebracht weiterhin das CU1 installieren zu wollen. Hat da einer eine Idee? Schönen Gruß, Roi Danton

Hat das Computerkonto Deines SiteServers SysAdmin Rechte an der Datenbank? (https://technet.microsoft.com/en-us/library/gg712320.aspx?f=255&MSPPError=-2147217396#BKMK_InstallSiteServer)

Hi zusammen, irgendwie gibt es keinen SharePoint Bereich im Forum oder ich habe ihn noch nicht entdeckt :) Ich hoffe mir kann trotzdem geholfen werden. Kennt jemand eine Möglichkeit die Microsoft SharePoint Hilfe offline verfügbar zu machen? In nicht mit dem Internet verbundenen Umgebungen ist das etwas unschön für die Nutzer, dass man die nicht nutzen kann. Ich hoffe einer kann da helfen. Schönen Gruß, Roi

Das ist nicht ganz richtig Nils. NTFS unterstützt nur 32768 Zeichen wenn diese nicht im Unicode vorliegen. Das ist keine GUI Beschränkung! Da aber der Explorer ausschließlich Unicode verwendet, sind es nur 255 Zeichen. ReFS kann jetzt 32768 Zeichen in UniCode. Somit kann es auch der Explorer und andere Anzeigen.

Ja, werde ich wohl so machen. Das dauert nur so ewig ;)