Jump to content

WSUSPraxis

Expert Member
  • Gesamte Inhalte

    4.240
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von WSUSPraxis

  1. Hallo und Guten Morgen,

     

    leider sehe ich Heute Morgen den Wald vor lauter Bäumen nicht und komme nicht wirklich weiter oder stehe völlig auf dem Schlauch.

     

    Eine Applikation schreibt in einen lokalen Ordner Dateien und erstellt auch Ordner mit Inhalt. Die Dateien haben verschiedene Datei Endungen.

     

    Die Ordner / Folder werden minütlich von der Applikation erstellt und in F:\foldername\" geschrieben. Liegt ein Order / Folder länger als 5 Minuten soll per Powershell Script eine Warnung ausgegeben werden "Found old Files" ! Das würde auch funktionieren wenn in den Ordnern / Foldern welche die Applikation erstellt, nicht auch Files vorhanden wären, welche älter als 5 Minuten sind. Diese sind teilweise viel älter - sind aber zwingend notwendig.

     

     

    $fullPath = "F:\foldername\"
    $numdays = 0
    $numhours = 0
    $nummins = 5
    
    
    
    function ShowOldFiles($path, $days, $hours, $mins)
    {
        $BaseDate = (Get-Date).AddDays(-$days).AddHours(-$hours).AddMinutes(-$mins)
        if (get-childitem $path -include *.* -recurse | where {$_.LastWriteTime -lt $BaseDate -and $_.psIsContainer -eq $false}) 
        {
                write-host "Found old files" -Fore Red
        }
    }
    
    ShowOldFiles $fullPath $numdays $numhours $nummins

     

    Die Ordner selbst welche erzeugt werden heißen immer spool_willkürliche Nummer und nur diese sollen überwacht werden.

     

    Jetzt zu meinem Problem:

     

    Wenn ich hier 

    -include *.* -recurse 

     

    etwas ändere läuft das Script nicht mehr oder es werden wieder die älteren Dateien aus den Ordnern gefunden.  Mit -filter usw... habe ich es auch schon probiert ! 

  2. vor 54 Minuten schrieb magicpeter:

    Moin Jan,
    danke dir für dein FeedBack. Ich bin noch am Planen und mache mir vorher die Gedanken. Schön zu hören das mein Plan auch so umgesetzt werden kann. Ich dokumentiere das jetzt noch und werde das dann nächste Woche durchführen, wenn Zeit ist. 

    Moin Ja,

    danke für deinen Input. Ja, so könnte man es auch machen. 

     

    Hallo Peter,

     

    und magst Du es so umsetzen ?

     

    Viele Grüße Arnd

  3. vor 5 Stunden schrieb NorbertFe:

    Und wieso? Die Mails durchlaufen wie alle Mails deren System. Damit ist grundsätzlich logischerweise auch der Zugriff darauf möglich. Ohne das jetzt für genanntes Produkt zu wissen, würde es mich wundern, wenn es nicht ginge. ;)

     

    Zugriff haben, Zugriff haben können, Zugriff sich verschaffen usw... Ist nach meiner Ansicht etwas anders, als die Mails laufen über ein Cloudsystem ?

  4. vor 2 Stunden schrieb MSExchangeAdmin:
     

    Hallo zusammen,

     

    Ich habe ein kleines Problem mit Distribution Groups bei Exchange 2016. Mit internen Konten funktionieren sie einwandfrei. An Mailkontakte (mit externer Mail-Adresse) werden die Mails allerdings nicht zugestellt, obwohl die externe Adresse als primäre Adresse eingestellt ist. Eine Fehlermeldung erhalte ich auch nicht (vermutlich, da die Mails an die Distribution Group grundsätzlich zugestellt werden und auch bei den internen Konten ankommen).

     

    Habt ihr eine Idee, warum Mails an Mailkontakte nicht zugestellt werden?

    Um den Fehlerraum weiter einzuschränken: Werden Mails an externe Kontakte über den Owner-Account der DList an die externe Adresse geschickt?

     

    Vielen Dank schon mal!

     

     

     

    Das Problem hat sich gelöst. Es lag am Spamfilter. Ein Klassiker also ;)

    Wir in einer Exchange Umgebung eine Universelle E-Mail-Verteilergruppe angelegt, so ist diese Gruppe nicht von extern zu erreichen und kann nur als interne Verteilergruppe verwendet werden. Dabei spielt es auch keine Rolle, ob diese Verteilergruppe über eine offizielle externe Email-Adresse verfügt oder eben nicht. Eine frisch angelegte Verteilergruppe funktioniert immer nur intern. Soll diese auch als öffentliche Verteilergruppe (die hinterlegte Email von außen erreichbar sein) dienen, so muss dies in den Einstellungen am Exchange Server hinterlegt werden.

  5. Terminalserver / Remotedesktop / Virtuelle Maschinen / VPN

    Die Konstellationen Terminalserver, Remotedesktop bzw. virtuelle Maschinen werden derzeit nicht offiziell von Lexware unterstützt, also nicht supportet. In der Praxis laufen die Programme in der Regel aber problemlos. 

     

    VPN Verbindungen zwischen verschiedenen Standorten und darüber erstellte Client-Server-Umgebungen sind technisch natürlich möglich. In der Praxis werdet Ihr damit aber sehr wenig bis gar keinen Spass bei der Arbeit haben. Ich kann daher eine solche Konstellation nicht empfehlen, offiziell unterstützt wird es zudem auch nicht.

     

    Das sagt der Lexware Support bei Lex Warenwirtschaft..... Bedeutet - Das Ihr bei Problemen, welche auch mit Lexware zu tun haben und nicht an der / mit der RDS Umgebung zu tun haben kein Support bekommt.

     

    Daher kann ich Euch nur dazu raten, Euch eine WAWI zu suchen, welche Terminal Server tauglich ist oder doch eine Cloud Variante. Was spricht geben SaaS Lösung ?

     

    Ich kann Euch aber wenig Empfehlen, da ich Eure Anforderungen nicht kenne.

     

    Viele Grüße Arnd

  6. Hallo und schönen Abend,

     

    Ausgangssituation: Lokales AD - AAD Connect mit msDS-ConsistencyGuid als SourceAnchor - Sync nach Azure AD

     

    Durch einen fehlerhaften User Restore haben 3 User das Problem, dass Sie sich nicht mehr am Azure AD / Office 365 anmelden können.

     

    Folgende Meldung befindet sich im AAD Connect:

    Zitat

     

    sync-rule-error-function-triggered

     

    Error in evaluation of expression: IIF(IsPresent([cloudSourceAnchor]), IIF(Word([cloudAnchor],1,"_")=[sourceObjectType],IIF([cloudSourceAnchor] = [sourceAnchor],[sourceAnchor],Error("SourceAnchor attribute has changed.")),[sourceAnchor]),[sourceAnchor])  Sync Rule: Out to AAD - User Join  Destination: sourceAnchor 

     

    InnerException=>SourceAnchor attribute has changed.

     

     

    => Der SourceAnchor Wert unterscheidet sich im Alten und Neuen Wert

     

    Leider habe  ich dazu nichts gefunden wie die User / Werte wieder gesynct  werden können ? 

     

    Ich würde mich über Eure Hilfe sehr freuen.

     

    Viele Grüße und schönen Abend

     

     

  7. vor einer Stunde schrieb tesso:

    Schau dir das Zertifikat und die Kette genauer an. Nach der Fehlermeldung könnte ein Stammzertifikat fehlen.

    Hallo und Guten Morgen,

     

    das es ein Zertifikat von einer Offiziellen PKI ist und die Kette installiert wurde - Nein - 

     

    Die Meldung kommt vom Internen Self Sign Zertifikat, welches nicht verwendet werden sollte.

     

    Viele Grüße Arnd

    vor einer Stunde schrieb cj_berlin:

    Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? 

    Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

    Hallo und Guten Morgen,

     

    Habe ich gerade nochmals gemacht. Session Host aus Collection genommen. Vererbung von GPO´s abgeschalten für die OU. Session Host wieder rein genommen.

     

    Leider das gleiche Problem. Es wird immer das Self Sign Zertifikat des Session Host verwendet.

     

    Viele Grüße Arnd

     

  8. Hallo und Guten Morgen,

     

    danke für deine Nachricht.

     

    Ich würde den Aufbau / Vorgehen nochmals genauer Beschreiben.

     

    =>  Wildcard Zertifikat wurde im Deploymend allen Rollen gleich zugewiesen und ist als Trusted gekennzeichnet

     

    => RDS Zugriff erfolgt üb er Collection Name   webwork.testdomain.de

     

              => Eingabe Benutzername und Kennwort  

              => Keine Zertifikatswarung

              => OK

     

    => Verbindung wird Hergestellt

     

    RDS.jpg.dfc55c25020427919c0fcd24c3540212.jpg

     

     

    Dann erscheint die Zertifikatsmeldung. Hier dann jeweils das Zertifikat des jeweiligen Session Host.

     

    Viele Grüße Arnd

     

  9. Hallo und Guten Abend,

     

    folgender Aufbau:

     

    2 x Windows Server 2019 Session Host(s)

     

    1 x Windows Server 2019 Session Brocker

     

    Session Hosts / Collection / Session Brocker und Lizenzserver sind konfiguriert - Bis hier funktioniert alles Einwandfrei

     

    Interne DNS Domain:     testdomain.de

     

    Offizielles Wildcard Zertifikat:  *.testdomain.de            SHA256

     

    Und hier beginnt mein Problem:

     

    Die Zertifikatszuweisung unter Edit Deploymend wurde gemacht und das Wildcard Zertifikat zugewiesen.

     

    Wenn ich nun das Zertifikat auf denn Session Host zuweisen möchte, dann finde ich hierzu keine Möglichkeit für ein SHA256 Zertifikat.

     

    Bei SHA 1 habe ich das immer so gemacht:

     

    $TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
    Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="Thumprint"}

     

    Leider funktioniert das mit SHA 256 Zertifikaten nicht ? Wie kann ich das Offizielle Wildcard Zertifikat den Session Hosts als RDP Zertifikat zuweisen ?

     

    Viele Grüße und Viele Dank

     

    Arnd

     

     

×
×
  • Neu erstellen...