mwiederkehr

So sollte es gehen:
$VMReplication = Get-VMReplication | select Name,Health,State foreach ($vm in $VMReplication) { $name = $vm.Name if ($vm.Health -Contains "Normal" -and $vm.State -Contains "Replicating") { # Mit $name ist alles OK } elseif ($vm.Health -eq "Warning") { # $name hat Warnungen } elseif ($vm.Health -eq "Critical") { # $name hat Fehler } } Bei Replikationen an externe Standorte mit nicht so hoher Bandbreite toleriere ich im Monitoring ein paar Stunden "Warning", denn das kommt meist, wenn er mit der Replikation nicht nachkommt und Zyklen verpasst. "Critical" ist aber eigentlich immer ein Fehler.

Es könnte helfen, die Datei "DefaultLayouts.xml" von "C:\Users\Default\AppData\Local\Microsoft\Windows\Shell" an den gleichen Ort im Profil zu kopieren, allenfalls ohne geöffnete explorer.exe.

Wir haben das mit Camtasia gemacht. Vorteil gegenüber TeamViewer: man kann die Videos bearbeiten: schneiden, Effekte (Pfeile etc.) einfügen und allenfalls Audio oder Untertitel hinzufügen.
 
Man kann die Videos als MP4 exportieren und es gibt einen Webplayer, mit welchem man das Video im Browser aus dem Intranet abspielen kann. Mit diesem Player hätte man dann auch erweiterte Features wie Quizzes im Video zur Verfügung.

Die Migration ist abgeschlossen. Es hat soweit alles funktioniert. Falls jemand mal vor der gleichen Aufgabe steht, hier eine kurze Zusammenfassung:
 
- AAD Connect eingerichtet, dabei das Attribut "msExchangeMailboxGuid" ausgeschlossen. Das ist wichtig, weil sonst auf Office 365 keine Mailboxen für die User erstellt werden, da sie lokal schon eine hätten.
- Allen Benutzern in Office 365 eine Lizenz zugewiesen. Dabei wird dann das Postfach erstellt. Dies dauert nur wenige Minuten.
- Alle Postfächer als PST exportiert und eine Mapping-Datei (CSV) erstellt. Mit dem Importer importiert. Hier ist es wichtig, genügend Zeit einzuplanen. Für die 26 GB (verteilt auf 550 Postfächer) hat sich der Importer fast zwei Tage Zeit gelassen.
- Getestet, ob das Login etc. funktioniert. Ging alles, auch Postfachberechtigungen wurden übernommen.
- MX umgestellt, Autodiscover-Eintrag gemacht, internen SCP entfernt (mit "Set-ClientAccessServer –Identity ServerName -AutoDiscoverServiceInternalUri $null").
- PST-Dateien nochmals exportiert, aber nur Elemente, welche nach dem letzten Export gesendet oder empfangen wurden. Beim Exchange 2010 musste ich dazu die Spracheinstellungen auf US stellen, da er sonst das Datumsformat nicht akzeptiert hat.
- PST-Dateien nochmals importiert. Ich habe sie mit AzCopy in ein Unterverzeichnis hochgeladen und die Mapping-Datei angepasst. Der Link zum Storage bleibt gleich.
- GPO erstellt, welche "https://autologon.microsoftazuread-sso.com" im IE der Intranetzone hinzufügt bzw. im Chrome der AuthServerWhitelist. Dies ist erforderlich für SSO.
 
SSO verhält sich wie folgt:
- neue Rechner (Windows 10, Office 2019, neue Profile): Beim Start sucht Outlook nach Mailkonten, zeigt die Adresse an und mit einem Klick wird das Konto eingerichtet. Im IE und Chrome kommt man ohne Kennworteingabe ins OWA, OneDrive etc. Lediglich die Mailadresse muss man angeben (oder man verwendet einen speziellen Link).
- alte Rechner (Windows 7, Office 2010, bestehendes Outlook-Profil): Da Outlook sich zum alten Exchange verbindet, repariert man das Profil. Dann muss man sich einloggen und Outlook neu starten. Es erscheint mehrmals die Kennwortabfrage, welche man wegklicken kann. Nach ca. 30 Sekunden erscheint die Meldung, der Administrator habe eine Änderung vorgenommen, welche einen Neustart von Outlook verlange. Nach dem zweiten Neustart ist Outlook mit Office 365 verbunden.
 
Fazit: Das "einfache" SSO über das Computerkonto ist eine sehr praktische Sache und funktioniert tadellos.

Das komische Verhalten tritt nur auf, wenn eine Endung vier Zeichen hat. "dir *.md" liefert nicht "test.mdf".
 
Es scheint mit einer "Emulation" von 8.3-Namen zu tun zu haben: https://social.technet.microsoft.com/Forums/windows/en-US/0b1a47a0-50ba-405d-9bd9-c66cf09fde04/dir-doc-returns-incorrect-files?forum=w7itprogeneral

Er ist schon noch auf der Website vorhanden: https://h10145.www1.hpe.com/downloads/DownloadSoftware.aspx?SoftwareReleaseUId=9191&ProductNumber=J9177A&lang=&cc=&prodSeriesId=&SerialNumber=&PurchaseDate=
 
Nur steht da etwas von "Trial" und dass man eine Lizenz benötige.

Die korrekte Methode scheint nicht "SaveAs2" zu sein, sondern "ExportAsFixedFormat":
https://msdn.microsoft.com/en-us/vba/word-vba/articles/document-exportasfixedformat-method-word
 
Dort den Parameter "UseISO19005_1" auf true setzen.

Das AD ist sehr vereinfacht gesagt eine Datenbank, welche Benutzer und Gruppen enthält. Anwendungen wie Windows oder Exchange führen Authentifizierungen über das AD aus. Dabei wird das AD immer vom Dienst, an welchem man sich anmeldet, kontaktiert, nicht vom Client direkt. Wenn sich also jemand am OWA vom Exchange anmeldet, kontaktiert der Exchange das AD, nicht der Browser vom Client. Deshalb muss das AD von aussen nicht erreichbar sein.
 
Auf der Firewall musst Du nichts von innen nach aussen blockieren, das AD baut nicht selbst Verbindungen zu irgendwelchen Servern im Internet auf.

Ich denke da kommt ihr nicht an SPLA vorbei. "Normale" Lizenzen gehen auf keinen Fall, wenn fremde Firmen auf der Plattform arbeiten. Microsoft CSP ist wie "testperson" schon geschrieben hat ein Modell zur Bestellung und Verrechnung von Office 365 (und soweit ich weiss auch Azure).
 
Windows müsstet ihr über SPLA lizenzieren, Office ginge dann mit Office 365-Lizenzen (Vorsicht: nicht alle Pläne gehen auf Terminalservern). Das Office auch über SPLA zu nehmen ist aber evtl. günstiger.
 
SPLA ist keine Hexerei: kompetenten Partner suchen, Vertrag abschliessen und dann jeden Monat den Lizenzbedarf melden. Die Software ist nicht anders, es sind nur andere Keys.

Bist Du sicher, dass Du die geordnete Liste angezeigt hast? In der normalen Ansicht hat die Reihenfolge der Regeln keine Auswirkungen bzw. spiegelt nicht dir angewandte Reihenfolge wieder.

Ich würde das Problem auch eher beim Router suchen. Denn der PC schickt die Pakete ja ans Gateway und das entscheidet, wohin sie weitergeleitet werden. Der PC kann einem Paket keine falschen Routinginformationen anhängen.
 
Funktioniert es, wenn der PC eine andere IP hat? (Vielleicht eine, die sonst ein anderer PC hat?)
 
Mir fallen zwei mögliche Ursachen ein:
- Tunnel ist zu eng (zum Beispiel von 192.168.178.1-192.168.178.250, der PC hat aber 192.168.178.251 bekommen)
- es existiert eine Policy Route auf dem Gateway, welche ins Internet zeigt (eher unwahrscheinlich, das hätte jemand bewusst einrichten müssen)

Das ist wohl kein Problem: Anleitung https://www.cisco.com/c/dam/en/us/td/docs/wireless/access_point/csbap/wap371/quick_guide/guide/QSG_ENGLISH.pdf, Seite 7:
 
Power Solid (Amber): The Cisco WAP371 is powered on, booting, or in normal operation with External Power Adapter
 
Grün ist die LED nur bei PoE.

Wenn Du an maier@gmail.com weiterleiten willst, muss diese Adresse nicht als Adresse eines Benutzers eingetragen werden. Der Mailserver ist ja nicht für gmail.com zuständig.
 
Es reicht, wenn Du einen Kontakt mit maier@gmail.com als Adresse erstellst und eine Verteilergruppe mit den beiden Adressen, die weitergeleitet werden sollen. Gruppenmitglied ist dann der Kontakt. (Also so, wie Norbert geschrieben hat.)

Ich sehe keinen Vorteil in mehreren Anschlüssen und mache pro IP immer einen Anschluss. So muss man nur einen Anschluss umstellen, falls ein Drucker mal eine andere IP bekommt.

Bei Disk2VHD sind sicher die Partitionen identisch, da ja ein Abbild in die VHD gemacht wird. Der "Rechner" selbst ist natürlich anders: anderes (virtuelles) Mainboard, andere Netzwerkkarte etc.
 
Nach meinen Erfahrungen kommt aber selbst Windows 2003 damit gut zurecht. Man muss es natürlich neu aktivieren und die Netzwerkkarte neu konfigurieren, aber starten tut es meist ohne Anpassungen. Falls es einen BlueScreen gibt, ist die Ursache meist ein fehlender bzw. nicht automatisch startender IDE-Treiber (falls der Server auf SCSI lief). Die notwendige Anpassung der Registry ist schnell erledigt, da man das VHD mounten kann: https://www.hyper-v-faq.com/ach-p2v-startet-die-hyper-vm-nicht-stattdessen-stop-0x0000007b.html

Das ist doch eine schöne Aufgabe, um erste Erfahrungen im Programmieren zu sammeln.
 
Ganz einfache Lösung: Ein PowerShell-Script, welches die Daten ausliest und mit ConvertTo-Html als HTML im Verzeichnis des Webservers speichert. Das Script wird per Taskplaner täglich oder stündlich gestartet.
 
Etwas komplexer, dafür mit mehr Funktionen: Eine Webanwendung (zB. ASP.NET), welche die Daten ausliest und darstellt, inkl. Suchfunktion etc.

Um das Thema abzuschliessen: Der Support hat nicht zuviel versprochen, seit dem Cumulative Update vom Juli funktionieren Verbindungen über das Gateway wieder.

Mit NFI aus den OEM Support Tools sollte es gehen: https://web.archive.org/web/20050403130000/http://download.microsoft.com/download/win2000srv/utility/3.0/nt45/en-us/oem3sr2.zip
 
siehe auch https://superuser.com/questions/97823/how-do-i-determine-what-file-occupies-a-given-sector

Hallo zusammen
 
Vielen Dank für eure Hilfe! Der Tipp, mal ICA zu probieren, hat mich zur Lösung geführt: Habe die VDA-Konfiguration geöffnet und nochmals den Server eingetragen. Danach funktionierten sowohl RDP als auch ICA.  :D
 
 Ich vermute die "von Benutzeraktivität verursachte Trennung" wurde vom VDA verursacht, weil der nach dem Klonen ein Problem hatte.