testperson

Dann stelle ich doch jetzt mal die Frage, wie du denn das MSI Paket verteilen / installieren willst? Ich erahne die Antwort schon und sage direkt: Nein, nicht per GPO! ;)

Hi, schau dir mal die Eigenschaften unter Allgemein der ps1 Datei an. Der zweite Screenshot (https://www.wintotal.de/tipp/abfrage-beim-oeffnen-einer-heruntergeladenen-datei-deaktivieren/) zeigt das was ich meine. ;) Gruß Jan

Hi, der Drucker ist installiert und eingerichtet und "nur" der Druck schlägt fehl? Muss ggfs. im Druckertreiber noch hinterlegt werden, dass eine Abteilungs-ID / Kostenstelle o.ä. erforderlich ist? Evtl. mal alle Registerkarten im Druckerobjekt auf dem alten Server mit denen auf dem neuen vergleichen. Gruß Jan

Hi, dazu müsstest du im Eventlog unter System diverse Einträge der Quelle Schannel finden. Sollte es daran liegen, einfach an Server und Client IIS Crypto von Nartac mit Best Practice ausführen. Gruß Jan

Hi, da wären Managed Service Accounts die bessere Wahl. Sofern die Applikation da keine Probleme mit hat. Gruß Jan

Ein Sinneswandel um 180° in nichtmal 24 Stunden. :-P

Da könntest du in die erste Antwort hier im Thread schauen. Ansonsten "pfusch" die Kosten für ein 3rd Party Tool doch einfach ins Budget für die vermutlich zeitnah anstehende Ablösung vom Exchange 2010. :)

Noch eine Anmerkung: Wenn du das Setup schon nach lokal kopierst, was durchaus sinnvoll sein kann, dann starte es auch von lokal. ;)

Hi, ggfs. machst du das einfach kurz & schmerzlos und nimmst z.B. von Code Two Exchange Rules pro oder MAPILab Attachment Save for Exchange. Gruß Jan

Hi, dann bau doch als erstes ein wenig Logging in dein Script ein, um zu prüfen, ob das Script startet und an welcher stelle es Probleme gibt. Dann könntest du mittels $setupPID = Start-Process -FilePath "<Pfad zur >\setup.exe" -Arguments "/Product:"SAPGUI" /silent" -PassThru noch den ExitCode loggen. Wenn die "setup.exe" dann tatsächlich startet, gibt es sicherlich auch noch einen Parameter, um die "setup.exe" zum loggen zu bewegen. ;) Gruß Jan

Nein. Du solltest den DC dann halt nur automatisch mit dem Host starten lassen, was ohnehin eine gute Idee ist. Die Hyper-V Dienste starten aber auch ohne erreichbaren DC. Die Anmeldung ist aber auch ohne DC per cached Credentials möglich. Und ganz im Notfall kannst du dich auch mit einem lokalen User am Hyper-V anmelden. Nein. Der Router sollte einfach auf einem Interface in deinem 10er Netz und mit einem anderen Interface i 192er Netz sein. Solange du dann keinen DHCP Helper o.ä. konfigurierst, bleibt DHCP ja im jeweiligen Netz. Es gibt doch sicherlich jemanden der das Gerät administriert. Da könnte man anfragen, ob derjenige nicht die Konfig entsprechend anpasst. Theoretisch ja. Aber ein Hyper-V Host sollte nicht auch noch ein Router sein bzw. keine weiteren Rollen wie Hyper-V ausführen. Außerdem hast du doch schon min. 2 Hardware Router. Ggfs. könnte das über eine Router / Firewall Appliance als VM gemacht werden.

(Ein deutlich einfacheres) Remote-Management. Eigentlich nicht.

OT: Ich verstehe es nicht, warum es in der IT so beliebt ist, mit irgendwelchen Würgarounds Probleme immer wieder / weiter zu umschiffen bis einem alles auf die Füße fällt... Und dazu fällt mir nur ein. ;) SCNR

Hi, natürlich gibt es firmen mit "interessanten" Vorstellungen wie z.B. dem 20-jährigen studierten ITler mit 10 Jahren Erfahrung der für den Mindestlohn arbeitet. Ebenso gibt es "interessante" Kandidaten mit ebenso kuriosen Vorstellungen. Auch wenn es wenig Geld ist, könnte es durchaus für die ausgeschriebene Stelle passend / üblich sein. Gruß Jan

Hi, einiges. ;) ich würde den Host ggfs. in die Domäne aufnehmen ich würde nur den DC als DNS am Host (und überall anders) nutzen ich würde in deiner beabsichtigten Konstellation den Server nicht multihomed mit 2 NICs betreiben sondern an einem / beiden Gateway(s) entsprechend die Netze routen Falls es unbedingt sein muss, würde ich das Gateway auf NIC2 entfernen und über eine statische Route routen Wenn DNS vom anderen Standort gebraucht wird, würde ich das über einen Forwarder am DC machen Da du jetzt vermutlich eine NIC "über" hast, würde ich NIC1 und NIC2 teamen Gruß Jan

Hi, bei vielen Dateien oder auch großen Dateien würde ich diese auf One Drive, Sharefile o.ä, ablegen und nur den Link versenden. Gruß Jan

Hi, wenn du in deinem Link links auf den Punkt unter "Grenzwerte" klickst, findest du auch noch ein paar hilfreiche Hinweise. Gruß Jan

Hi, warum zwei Domains? Warum kein Trust? Spontan wäre es wohl am einfachsten, am Standort A einen Terminalserver zu betreiben an dem sich die User aus B mit Ihren Konten von A anmelden. Ich hätte aber schon keine Lust auf doppelte Kontenführung. ;) Gruß Jan

Ich bezog mich auf die Möglichkeit mittels des verlinkten DSInternals PS Moduls aus meinem Beitrag. Da werden halt die Hashes der User Passwörter ausgelesen und mit den gehashten Einträgen aus der Passwortliste abgeglichen.

Z.B. das du Passwörter der User "ausliest", der User nichts davon mitbekommt und du (oder jemand anders) sich als User ohne sein Wissen / Einverständnis anmelden kann. Ich finde es jedenfalls grenzwertig so etwas ohne Info an den User zu unternehmen.

Hi, nein. Mir hatte ADN das mal ans Herz gelegt. Durchaus möglich, dass das auch damit zu tun hat, das ADN Reseller davon ist. ;) Ich hatte mir SILA / SIL mal angeguckt (https://blogs.technet.microsoft.com/hybridcloudbp/2016/02/05/spla-reporting-introduction/). Aber auch das nutzen wir nicht. "Ich" liefere lediglich über den Citrix Lizenzmanager bzw. LUI die monatlichen User. Irgendwie wird daraus dann mit für mich *MAGIC* das SPLA Reporting gemacht. Gruß Jan

Hi, um den Helpdesk mit sowas nicht zu belasten, kann man das auch mit z.B. CodeTwo Exchange Rules Pro an die Abteilungen selber delegieren. Gruß Jan

Ein wenig OT: Es gibt zumindest Tools, die diese Links in Office Dokumenten korriegern können sollen.

Hi, im DSInternals PowerShell Modul (https://www.powershellgallery.com/packages/DSInternals/3.5) gibt es auch entsprechende Funktionen (http://www.stephenthompson.tech/audit-ad-passwords-with-powershell/). Allerdings musst du dort auch selber eine entsprechende "Bad Password List" erstellen. Generell sollte man sich aber vorher wohl mal mit Betriebsrat o.ä. zusammensetzen, ob man das "mal eben so" darf. Gruß Jan

Hi, wenn es um SPLA geht ggfs. https://www.octopus.cloud/de Gruß Jan