Jump to content

blub

Expert Member
  • Gesamte Inhalte

    7.598
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von blub

  1. Werde mal drüber nachdenken, inwieweit die Rückfragen für mich zur Lösung der Darstellungsprobleme in IE, Chrome und Firefox beitragen ;-)

     

    Ist halt ärgerlich, wenn Miicrosoft ewig lang mein System scannt, mir schließlich meldet, daß es weder mit Hard- noch mit Software Probleme gibt, um nach den Upgrade zu sagen "April, April - das Programm blockiere ich" und mit 4 (1) "Unbekannte Geräte" im Gerätemanager ohne jegliche weitere Info anzuzuzeigen.

     

    Zu Deinen Fragen:

    - das Backupprogramm ist 2 Jahre alt und solange ich nicht auf das NDAS zugreifen kann, mache ich mir da keine weiteren Gedanken

    - Für die aktuellere Paßwortverwaltung müßte ich tief in die Tasche greifen, aber auch sie arbeitet nicht mit Edge, sondern nur mit den anderen Browsern

    - der 64-Bit NDAS-Treiber hat einwandfrei mit Win7 gearbeitet, aber der Hersteller Ximeta ist weg vom Fenster, also keine Aktualisierung zu bekommen (in der W10 32-Bit-Version gibt es dieses NDAS-Problem nicht)

    - Ich verwende lediglich die Windows-Firewall und die ist aktuell

    Ich will Microsoft jetzt nicht verteidigen. Es ist m.E. aber in der Verantwortung des Users, bzw. 3rd Party Herstellern für funktionierende Treiber und Software zu sorgen. Wenn der Hersteller deiner Passwortverwaltung am OS-Update kräfitg mit verdienen will, tja ..,aber dafür kann MS nun nichts.

    "Das Programm blockiere ich" kann Windows auch erst sagen, wenn es ausgeführt wird.

    Benutze Software von einigermaßen namhaften Herstellern, dann kannst du auf deren Websites immer sehen, unter welchen Betriebssystemen die Software noch lauffähig ist oder was ein Update kostet.

     

    Dein Schicksal mit der Browserdarstellung  ist sicher bedauerlich, aber es ist ein Einzelschicksal. Es wird also an irgendeinem Treiber oder einer Software (auch Malware wäre möglich) liegen, die du bei deinem Inplace Upgrade von Win7 auf Win10 mit rüber gezogen hast.

    http://www.mcseboard.de/topic/206870-erhebliche-darstellungsprobleme-im-ie/?p=1304223

     

    blub

  2. Noch ein Tipp:

    Installiere den Server zumindest aus Securitysicht (Patches, Security-Policies, Virenscanner, etc.) komplett fertig in einer abgeschotteten Umgebung. Erst dann schieb ihn ins Produktionsnetz und haenge ihn dort mit deinem Skript in die Domäne.

    Nicht wie oben geschrieben, die 'restlichen Installationen' erst nach dem Join

     

    Blub

  3. Ein zweiter DC oder 1000€ Einsatz verbessern alleine eine systemisch schlecht aufgesetzte Single-DC Umgebung noch lange nicht. Zum Blumenstrauß der bisherigen Risiken werden nur noch Replikationsprobleme hinzu kommen. 

    Verkorkste Umgebungen gerade zu biegen ist meist teuerer, als nur eine neue Hardware dazu zu stellen.

     

    Ganz allgemein gesprochen, ohne Bezug auf das hier besprochen AD!

  4. Mit dem -lt Operator für Strings musst du sehr aufpassen, ob der wirklich immer das macht und machen wird, was du erwartest!

     

    zählt Java z.b. die letzte Nummer/String immer zweistellig? ( ich würde mir die Java-Versionierung jedenfalls genau ansehen)

    '8.0.1010.2' -lt '8.0.1010.13' ->false

    oder

    '8.0.1010.02' -lt '8.0.1010.13' ->true

     

     

    die erste Nummer/ String aus deinem Beispiel ist ebenso eine Zeitbombe.

    '10.0.1010.13' -lt '8.0.1010.13' -> true

     

    -lt, -gt sind ansich für numerische Werte. -Like und -Match ggf. mit "regular expressions" sind für Strings

  5. Hallo,

    Wenn ich dich richtig verstanden habe, würde ich es so strukturieren.

    $myName = "Java" #da unten mit "-eq" gearbeitet wird, ist der genaue String erforderlich. Sonst nimm "-like"
    $myVersion = "8 Update 101" #ggf mit Platzhalter "*" arbeiten
    
    $Products = @((Get-WmiObject -Class Win32_Product | Where { $_.Name -eq $myName -and $_.Version -notlike $myVersion })
    
    Foreach ($Product in $Products){
        $Product.IdentifyingNumber
        $Product.Version
        
        #Msiexec......
        
        #aber Win32_Product() hat auch eine eigenen uninstall-Methode
        #$Product.Uninstall()  #https://msdn.microsoft.com/en-us/library/aa394378(v=vs.85).aspx 
    }
    

    blub

  6. ich seh's genau andersrum:

    Die lokale Verarbeitungsgeschwindigkeit eines leeren Policyteils und eines disabled Policyteils wird exakt gleich sein. Beide male nahe 0. Die 0,35s Zeitdifferenz auf der Website schiebe ich auf Messungenauigkeit.

    Ob eine Policy gar nicht, oder eben (unnötigerweise) komplett vom Client bzw. User abgeholt werden muss, das hingegen macht einen Unterschied. Ob User den Unterschied merken, hängt aber von vielen Faktoren ab: Je dünner die Leitungen, je älter die Hardware und Betriebssysteme, je größer die Policies, je mehr User und Clients, je weniger DCs, umso eher wird ein nicht optimiertes GPO-Management ins Gewicht fallen.

     

    aber wiegesagt: abstrakte Theorie smile.gif. Ich habe jetzt auch keine Lust oder Bedarf hierzu selbst Messungen anzuwerfen.

  7. Hallo,

     

    Soweit ich die GPO Verarbeitung verstehe:

     

    - Jeder Client/ User frägt per LDAP einen DC nach den für ihn passende Policies

    - Der DC sendet eine Liste mit LDAP an zugewiesenen GPOs wieder an den Client/ User zurück

    - Der Client/ User holt sich die ihm zugewiesenen GPOs vom Sysvol des DCs über SMB

    - Abschließend werden die GPOs lokal am Client verarbeitet und auch gecached.

     

    Pro aktiver, angewendeter GPO  geht bei jeder Aktualisierung extra LDAP und SMB Traffik zwischen Client und DC hin-und her. Caching verringert den Traffik sicherlich.

    Bei wenigen User/ Clients und Policies macht das Deaktivieren von GPOs sicher nicht viel aus, aber bei vielen GPOs und vielen Clients und vielen Usern multipliziert sich der LDAP/ SMB Traffic. Wenn eine Policy z.B. keinen Userteil enthält, kann/ sollte man sich diesen damit überflüssigen Prozess für diese GPO mit einem einfachen Mausklick zum Deaktivieren der Userobjekte sparen.

    Zumindest meine abstrakte Meinung :)

     

    blub

  8.  

    10.10.15/XY/REQ-2015-12345 (User erstellt)

    Die Information "User erstellt am 10.10.15" hast du redundant an mindestens drei Stellen

    - dieses unstrukturierte Beschreibungsfeld

    - im UserCreated-Attribut

    - in deinem Ticket REQ-2015-12345

    - ..

    Redundanz ist nicht gut für Datensätze.

     

    Ich würde ins AD nur Daten schreiben, nach denen man mit LDAP sinnvoll filtern kann.

    Prinzipiell ist euer Ansinnen nach "Datenhygiene" sicher sinnvoll.  Useraccounts, von denen keiner mehr weiß, "wer, warum und wann die erstellt bzw. beauftragt hat", sind ein erhebliches Risiko!

     

    blub

  9. Je nach Größe deiner Umgebung würde ich mir ggf. Gedanken machen, z.B. IP-Netze,  Windows Firewall, Active Directory Sites, Netzwerkkomponenten (wie z.B. Firewalls), Security-Tools, GPO-Settings, mobile devices, alt-Linux Systeme, etc,etc. Vieles davon kann zumindest auf IPv4 Adressen basieren, und muss für IPv6-Traffic umkonfiguriert werden oder kann evt. gar nicht mit IPv6 kommunizieren.

    Unvorbereitet  läufst du die nächsten 20 Jahre zweigleisig, wenn kein Plan existert, die Migration IPv4 -> IPv6 auch mal abzuschließen. Anstatt Gewinn, zahlst du dann drauf.

    Ich bin einfach kein Freund von "schalts halt ein, noch ein Haken irgendwo ... und gut is".

×
×
  • Neu erstellen...