-
Gesamte Inhalte
4.240 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von WSUSPraxis
-
-
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 !
-
Hallo und Guten Morgen,
ich bin auf jeden Fall dabei.
Viele Grüße Arnd
-
Hallo und Guten BpDk,
das Problem ist leider bekannt und wird zur Zeit von Microsoft so für Office 365 nicht unterstützt. Du musst Dir selbst eine andere Lösung bauen oder den Prozess umstellen.
Viele Grüße Arnd
-
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
-
Hallo Norbert,
einer Software welche Made in Germany ist, welche BSI und ISO zertifiziert ist usw... Der Vertraue ich Persönlich erst einmal und dem Anbieter vertraue ich erst
einmal !
Viele Grüße Arnd
-
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 ?
-
vor 18 Stunden schrieb winmadness:
Technisch haben die Admins von NoSpamProxy Zugriff auf die EMails, würden diesen aber "nicht nutzen".
Also ich würde jetzt mal sagen ! Die Aussage stimmt nicht.
-
vor 3 Stunden schrieb Nobbyaushb:
Wenn das was kosten darf und auch auf einer Windows-Maschine, dann den NosSpamProxy - ich glaube, den gibt es mittlerweile als Cloud-Service
Das wäre auch genau meine Empfehlung.
Viele Grüße Arnd
-
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.
-
vor 2 Stunden schrieb MSExchangeAdmin:
Danke für die zahlreichen Tipps und Erklärungen. Ich habe das AD nun ganz klassisch, wie angeraten, "nach Lehrbuch" migriert.
Mich würde interessieren was Du jetzt genau wie gemacht hast ?
-
vor 5 Stunden schrieb cj_berlin:
Schon, aber das Clerainghouse hat ja keine Informationen darüber, was für Lizenzen Du irgendwo herum liegen hast
Warum sollte das Clearinghouse das auch tun ?
-
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
-
Hallo und schönen Mittag,
um welches Lexware Produkt handelt es sich ? Nicht alle / sehr viele sind nicht für den Betrieb auf Terminal Server / RDS Umgebungen freigegeben.
Viele Grüße Arnd
-
Hallo und Mittag,
wenn möglich machen wir das bei unseren Kunden:
RDSH über RD Gateway mit Token, von dort auf Server / Jumphosts / PAWs / Web-Oberflächen + Monitoring und bei Bedarf auch werden die Zeiten eingeschränkt wo zugegriffen werden darf.
Viele Grüße Arnd
-
Klasse - Dann passt das Ja !
- 1
-
Hallo und Mittag,
mit der passenden ISO geht das Problemlos.
Viele Grüße Arnd
- 2
-
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:
Zitatsync-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
-
Hallo Evgenij,
danke Dir für den Einsatz.
Okay jetzt wird es extrem Verrückt ! Wenn ich mir das RDP File über RDWEB runterlade und verwende - Dann kommt keine Warnung ? Wo liegt mein Denkfehler ?
Viele Grüße Arnd
-
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
-
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
Dann erscheint die Zertifikatsmeldung. Hier dann jeweils das Zertifikat des jeweiligen Session Host.
Viele Grüße Arnd
-
Hallo Thomas,
danke Dir trotzdem ! Leider komme ich garnicht weiter..
Viele Grüße Arnd
-
Hallo und Mahlzeit,
Danke Dir ! Ja so habe ich es konfiguriert. Aber so wird nach meiner Ansicht nicht den Session Host das RDS Listener Zertifikat zugewiesen ?
Viele Grüße Arnd
-
Hallo und Guten Morgen,
ich habe die Nacht geforscht und alles probiert ! Doch leider habe ich nichts dazu gefunden.
Viele Grüße Arnd
-
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
Script - Ordner liegt länger als 5 Minuten im Verzeichnis
in Windows Forum — Scripting
Geschrieben
Hallo und Abend,
danke Dir ! Das war mein Fehler !