testperson

In deinem Fall müsste es Start-Process powershell -Credential $credential -ArgumentList $("-File " + $script) sein. (Optimalerweise bzw.) ich baue mir das immer so: $PowerShellPath = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" $PowerShellArgs = $("-NoProfile -ExecutionPolicy Bypass -File " + $script) Start-Process $PowerShellPath -Credential $credential -ArgumentList $PowerShellArgs

Möglichkeit 1) Du lebst jetzt die "wenigen Wochen" weiter damit. Möglichkeit 2) Du konfigurierst den Exchange noch in Richtung Best Practice (SplitDNS + passendes Autodiscover für die primären SMTP Adressen + passendes Zertifikat). Dann siehst du weiter.

Entweder muss da $script weg oder du benötigst noch "-Argumentlist $script". Oder es ist noch was ganz anderes. ;) Dafür müsste man aber jetzt nochmal den Rest vom Script sehen.

In dem Fall musst du aus $password noch einen SecureString machen. ;) $User = "PC\User" $Password = "HierDasPasswortDenken" New-Object -TypeName System.Management.Automation.PSCredential ($User, $(ConvertTo-SecureString $Password -AsPlainText -Force)) oder eben $User = "PC\User" $Password = ConvertTo-SecureString "HierDasPasswortDenken" -AsPlainText -Force New-Object -TypeName System.Management.Automation.PSCredential ($User, $Password)

Hi, dann hast du mit Sicherheit an den Default Konnektoren gespielt. Funktioniert das Mailrouting vom Exchange 2013 zum 2010? Dann lass den 2013 die Mails annehmen. ;) Was findest du denn im SMTP Log? Generell würde ich noch fragen wollen, warum jetzt noch zu 2013? Gruß Jan

Ich würde an dieser Stelle ansetzen und das anpassen bzw. korrigieren. Welcher CN (und welche SANs) stehen denn im Zertifikat? Sprichst du hier von AD Domäne(n) oder einfach nur von akzeptierten (E-Mail) Domänen? Im (hoffentlich) letzten Fall, könnte ein fehlendes autodiscover.gfd.de im Zertifikat fehlen.

Du liest ein verschlüsseltes Passwort aus der Datei ein, verschlüsselst es nochmal und entschlüsselst es wieder. Du müsstest wohl den mittleren Part raus lassen. Ansonsten teste es einfach erstmal mit Zugangsdaten im Plaintext. Wenn das läuft, den nächsten Step machen.

Wenn das Passwort auf PC1 verschlüsselt wird und auf PC2 entschlüsselt / genutzt werden soll, dann muss AFAIK ein Key genutzt werden.

Nutzen die einigen wenigen PCs keinen Proxy und der Rest schon? Funktioniert es auf den "wenigen PCs" mit allen Usern bzw. funktionieren die User der "wenigen PCs" auch auf den anderen PCs? Das Zertifikat ist von einer CA oder self signed? Wird SplitDNS genutzt? Gibt es einen Loadbalancer / Reverse Proxy?

Hi, das Outlook ist auch aktuell gepatched? Ggfs. ExcludeExplicitO365Endpoint und evtl. ExcludeHttpsRootDomain aus https://support.microsoft.com/en-us/help/2212902/unexpected-autodiscover-behavior-when-you-have-registry-settings-under Gruß Jan

Wenn nirgendwo geloggt wird, musst du wohl was Logging einbauen. Evtl. mal ganz "stumpf" vor der PowerShell Zeile ein "pause" und danach auch. Um zu prüfen, ob das Skript gestartet wird oder auch nicht, kannst du im PowerShell Script auch einmal ein "pause" einbauen.

Hi, keine Ahnung ob "-command" auch funktionieren sollte. Ein Script sollte allerdings mit "-File <Pfad zum Script>" gestartet werden. Ansonsten würde ich noch "-NoProfile" nutzen. Testweise kannst du mal "-ExecutionPolicy Bypass" versuchen. Gruß Jan

Hi, du musst vermutlich nur "-Tail 1" an deine Zeile zum Einlesen hängen (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-content?view=powershell-6). ;) Gruß Jan

Hi, du solltest evtl. gaaaaanz vorne anfangen. Was darf wie lange ausfallen (RTO)? Wie viel Datenverlust ist akzeptabel (RPO)? Gruß Jan

Hi, das Exchange Team hat den Exchange 2019 Sizing Calculator (https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Announcing-The-Exchange-Server-2019-Sizing-Calculator/ba-p/644180) angekündigt. Schauen wir mal was der so kalkuliert. Allerdings: Gruß Jan

Auf _dem_ Terminalserver kannst du nur Apps bereitstellen, die auch auf _diesem_ Terminalserver installiert sind. Die anderen Server können allerdings auch Apps bereitstellen, solange Sie auch Terminalserver sind.

Hi, einfach den RDS Lizenzserver installieren, aktivieren und dann keine CALs installieren. Dann solltest du 60 oder 90 Tage Zeit haben. Der Admin und ggfs. die User bekommen dann allerdings nur immer mal wieder die Meldung, dass keine RDS CALs installiert sind. Das könnte auch ohne RDS Lizenzserver gehen, dann wäre die "Fehlermeldung" halt nur, dass kein RDS Lizenzserver gefunden wird. Gruß Jan

Ohne Garantie / Support aber auch irgendwie nicht der Bringer. Bei fast jedem Hersteller gibt es doch Micro- / Mini-Server. Da sollte man inkl. Lizenz irgendwo ganz am Anfang von vierstelligen Euro Beträgen landen.

Unterm Strich tut das keine "Alternative-Frontend-Lösung". ;) Nach den letzten Infos des TO wäre aber wohl der derzeit beste Ansatz.

Wie weit bist du denn mit "VDI"? Gibt es schon eine entsprechende Infrastruktur oder bist du noch in der Planung? Welche VDI Lösung setzt du ein / planst du einzusetzen? Da solltest du in der entsprechenden Hersteller Doku sicherlich fündig werden. Ebenfalls wäre noch interessant was für Daten du da in welchen Mengen hin und her kopieren möchtest? Wie gesagt, es gibt mehrere Wege.

Hi, in der Regel kannst du Laufwerke über das entsprechende Protokoll in die VDI Session mappen lassen. Ggfs. lassen sich auch die Netzlaufwerke, die in der VDI Session sind am Client verbinden. Ansonsten wäre sicherlich auch Sharefile, OneDrive, etc. ein Ansatz. Generell gibt es Wege, es kommt halt drauf an. ;) Gruß Jan

Hi, mir kommt grade noch Just Enough Administration in den Sinn. Damit sollte das ggfs. auch realisierbar sein: https://docs.microsoft.com/de-de/powershell/jea/role-capabilities#create-a-role-capability-file Wäre dann wohl der Ansatz. Gruß Jan

Ich lese daraus, dass der Admin in seiner OU Gruppen erstellen und in diese Gruppen Userkonten / Computerkonten aus dem gesamten AD hinzufügen kann, aber nicht soll. Aber warten wir mal ab. :)

Hi, mir würde spontan ein alternatives, angepasstes "Frontend" einfallen, das dem User nur das zeigt bzw. anbietet, was er sehen / nutzen darf. Ggfs. halt auch eine 3rd Party ala Manage Engine AD Manager plus, Quest Active Roles oder eine "User-On-Boarding-Lösung". Ansonsten den User in eine Gruppe packen und der Gruppe das Recht "Lesen" bzw. "Inhalt auflisten" auf den OUs zu nehmen / verweigern, wo er nichts sehen / nutzen soll. An dieser Stelle wäre allerdings Dokumentation, nur Gruppen berechtigen und Dokumentation das wichtigste, was auch für die Delegation gilt. Gruß Jan

Das müsste / sollte / könnte auch mit zwei FritzBoxen gehen. Ggfs. auch mit einer, sofern man da am Gast Netzwerk die Subnetmaske ändern kann.