4zap

Ok, dann würde ich mir mal einen USB Ethernetadapter schnappen und schauen ob die PCs damit ins Netz kommen. Damit spart man sich den Einbau von neuen NiCs. Nur zum Testen falls du so ein Ding irgendwo zufällig rumliegen hast. Ergibt vielleicht neue Erkenntnisse beim Testen.

Hähähä.... ich hab letztens ein IP Kamera Netzwerk gesehen wo der Techniker 4 IP Kameras an ein Netzwerkkabel gefummelt hat. ohne Switch dazwischen. Alle 4 hatten eine valide IP über DHCP, lediglich die Bildqualiät war mies. Das das überhaupt funktioniert erschloss sich mir nicht. Es hätte nie funktionieren dürfen. Den Trick hat er mir leider nicht verraten. Bei 4 Adern pro Kamera hätte ich es noch verstanden aber so.... Ein ähnliches Phänomen wie Sir Michael hatte ich mal mit einem Soho Router mit Switch drin. Nachdem eine ordentliche Appliance gekauft wurde hörte das schlagartig auf. Ich bekam aber immer die Meldung die IP wäre schon vergeben, Netzwerkadapter deaktiviert. Die vermisse ich hier. War ein Family Router der Telekom. Ich vermute hier etwas ähnliches. Das ist irgendeine aktive Komponente im Netzwerk defekt.

ich glaub das ganze AD ist total versemmelt bei den DNS Fehlern. Da fehlt jegliche MSBP. Ich will nicht wissen wie der DHCP aussieht. Das grade zu ziehen (auch vor Ort) ist mutig. Sauber neu aufsetzen halte ich für die bessere Lösung.

mach doch mal AD Domänen und Standorte Konsole auf. Stimmt die Konfig dort? Glaub nicht. Ich würde erstmal aufräumen dort und alles grade ziehen bevor du irgendwo rumfummelst.

Es ist nur noch 1 DC online? Dann bitte ein dcdiag /test:dns ohne /e. Weil eine Gesamtstruktur gibt es ja nicht, ist soweit ich das sehe 1 single Domain Controller. Wenn 192.168,1,253 offline ist dann ohne /e. Kann ja nur Fehler ausspucken.

dcdiag sagt dir wo es klemmt. /e bedeutet die Gesamtstruktur wird getestet, ohne /e nur der eigene DNS Dienst auf diesem DC. dcdiag /test:dns /e Poste mal den Output.

Wir arbeiten auch mit kleinen Netzmasken da wir pro Standort mehrere tausend IPs im Subnet benötigen. Wenn DHCP zickt die Switche neu starten. Bei Layer3 Switchen (die aber Layer3 deaktiviert haben) kommt es aus meiner Erfahrung schonmal vor das die den DHCP Broadcast zwar überall weiterleiten aber den DHCP Offer nicht mehr zum Client zurückschicken. Ein Neustart des betroffenen Swichtes oder aller ist dann der erste Schritt. Wir haben einen zweiten DHCP Server im Netz aufgestellt und den DHCP Bereich gesplittet. Daher seh ich am Client immer sofort ob die IP vom DC oder vom zweiten DHCP kommt. Dann weiß ich der DHCP Offer klemmt schon wieder am DC. Bei eurem Phänomen könnte ich mir vorstellen das ihr mit der DHCP Konfig am Server rumprobiert habt in diverse Szenarien. Vielleicht waren da irgendwo Karteileichen von Adressbereichen in der Reg drin und nach der Neukonfiguration waren die RegEinträge wieder eindeutig.

Ja genau und deshalb rate ich Unternehmen immer bereits im Arbeitsvertrag zu definieren das private Emails und Kommunikation (S4B, Teams usw) verboten sind. Damit schließt man eine Menge Ärger und Diskussion schon im Vorfeld aus. Beispiel: Mitarbeiter wird krank, Firma braucht aber aktuelle Emails - Vollzugriff für Vertetung wird eingerichtet.... wären hier private Mails drin wäre das schon ein Problem und wird deshalb untersagt. Heutzutage rennt jeder mit Handy rum... privater Krempel ist da auch nicht mehr notwendig. Wenn man das so handhabt wird das Thema Email und Archivierung relativ unkompliziert.

Für Privat nicht, Kaufleute, Handelsgesellschaften, eingetragene Genossenschaften und jede juristische Person die Handelsgeschäfte abwickelt ist hier betroffen. https://www.gesetze-im-internet.de/hgb/__257.html Ist ganz interessant ...

Defender ist richtig gut geworden. Ich betreibe keine Drittanbieter Virensoftware mehr auf 2016 Servern. Hat auch den Hintergrund das unser AD komplett intra ist und es keine offenen public Endpoints gibt. Es wird alles über den SCCM verwaltet und reported. Außer PUP und solche Kleinigkeiten ist in den letzten 3 Jahren nix passiert. Haupteinfallstor waren eh die Outlook Konten, auch dort hat O365 gute Mechanismen zur Malwarefilterung. Diverse Phishing Kampagnen gingen schief. Das hätte auch eine Symantec nicht verhindert. Da kommts eher drauf an das die User geschult sind. Drittanbieter Software ist richtig teuer in der Lizensierung und das Business Value ist schon lange nicht mehr gegeben. Alleine schon der Performanceeinbruch nach der Erstinstallation bringt mich zum Erbrechen und die ganze Vewaltung davon. Das kann man sich bei 2016 echt sparen m. E. nach.

Ja, das ist gesetzlich vorgeschrieben. Emailverkehr muss min. 10 Jahre manipulationssicher archiviert werden in DE. Mailstore Server ist eine Lösung dafür. Soweit mir bekannt reicht auch das InSitu Archiv von O365. Hatte letztens einen Fall wo ein Postfach komplett exportiert und an entsprechende Stellen ausgehändigt werden musste. Der Export aus dem Archiv hat denen genügt.

Passiert das auf allen Clients mit Win10? Ich würde die Kiste aus der Domäne kicken (lokales adminpasswort nicht vergessen) und nochmal joinen.

Hallo ich muss Daten am Ars** der Welt für User bereitstellen die auch hier lokal auf einem Synology NAS verwendet werden. Azure ist dort für mich verfügbar. Zugriff soll über https erfolgen, der Storage wird als Netzlaufwerk eingebunden. Dabei ergeben sich aber Probleme: - ich kann mit dem Synology Cloud Sync in einen Azure Blob Storage syncen, das geht -> den kann ich über https in Azure aber nicht freigeben -ich kann NICHT mit dem Synology Cloud Sync in eine Azure File share syncen (was am einfachsten wäre im gleichen Speicherkonto) -> den könnte ich aber dann als Netzlaufwerk verbinden Welche Optionen hab ich noch? Die Daten sollen so nah wie möglich am User dran sein. Gibt es Apps für Synology die man nutzen kann? -OneDrive scheidet aus Irgendwelche Ideen die nicht so arg kompliziert sind? viele Grüße

Ist doch gar nicht Montag heute...anstatt des Thumbprints nimmt man besser den öffentlichen Schlüssel... ich Hasenhirn. Falls der Fehler mit dem Zertifikatsnamen auftaucht muss es nicht unbedingt daran liegen. Es geht jetzt....cer als base64 x509 exportieren, mit Textdatei öffnen, der Öffentlichen Schlüssel rauskopieren und in die Spalte public certificate data eintragen.

Moin, ich hab ihm Azure ein neues ARM Vnet aufgespannt mit Vnet Gatway. Dort versuche ich die point2site Verbindung einzurichten mit einem selbstsignierten Zertifikat. Vor drei Jahren hab ich im alten classic model die fast identische Konfig ausgerollt. Wenn ich im Azure portal da rein schaue sehe ich den zertifikatsnamen mit "CN=FIRMA-ENT-CA,corp,DC=fima,DC=com" in der alten classic Verbindung. Irgendwie hab ich es damals über Powershell geschafft das RootCer für die p2s Verbindung ins azure zu laden. Ich will ja nur den NAmen und den Thumbprint ins Azure schreiben, jedoch erhalten ich beim Zertifikatsnamen einen Error. Zertifikatsname ist nicht gülitg.... Egal wie ich den Namen setzen will, azure nimmts nicht. Das Zerti ist ausgestellt für: FIRMA-ENT-CA, so steht es auch auf dem Zertifikat. Weder die CN Schreibweise noch den reinen String vom Zertifikatsnamen wird akzeptiert. Ich weiß das ich damals auch Ärger hatte das zu integrieren und ich weiß nicht mehr genau wie ich es geschafft habe. Ich versuchs nochmal das Zertifikat über PS ins Azure zu laden aber eigentlich ist das schon vorhanden im Zertifikatsspeicher, es würde reichen Thumbprint und NAme zu definieren. Hat von euch jemand noch einen Tipp? Google Workarounds haben nicht geholfen und ich erinner mich nicht mehr wie es damals hingekriegt hab. :( ah ich sehe in der Doku im alten Portal gabs einen Button zum Upload.... so hats also damals funktioniert... beim neuen Portal muss es wohl mit PS gehen.

Das wäre auch meine erste Frage.... müsste ja der DC sein auf dem auch AAD Connect läuft.... sonst rennt man ins Leere.

Die Frage wäre was du erreichen willst? Windows10 VM kannst du dir erstellen in Azure aber wieso "anmelden"? Versteh ich nciht. AaD Connector ist ein reines Sync Tool, damit syncst du die gewünschten Daten und Attribute von onrpem AD zu Azure AD. Daher verstehe ich die Frage nicht richtig .... Zwingend benötigt wird es nicht. Soll im Azure ein AD aufgespannt werden oder willst du nur einzelne Maschinen dort hochziehen?

Da bin ich ganz bei dir. Aber manche Entscheidungen vom Management setzt man um, da nutzt kein Diskutieren mehr. Die sind da absolut beratungsresistent. Bei Outlook2016 reicht es wenn ich in die Reg ein paar Keys reinschreibe und der Mailabruf erfolgt dann tatsächlich erst nach Ablauf der gesetzten Zeit. Die GPO schreibt folgendes in die Client reg um den Mailabruf alle 6h auszuführen (falls mal jemand danach suchen sollte)

Hi ich soll einer AD Gruppe per GPO den Mailabrufintervall zentral steuern, d. h. diese Gruppe soll nur alle 6h in Outlook Emails empfangen. Zu allen anderen Zeiten sollen die Emails nicht automatisch eintrudeln. Eine ADMX Vorlage für Outlook2016 hab ich nicht finden können. Mit Procmon hab ich versucht die Reg Änderungen zu erfassen die erfolgen wenn ich das in Outlook selbst ändere, aber da sieht man den Wald vor lauter Bäumen nicht mehr. Hat das schonmal jemand umgesetzt und kann mir Tipps geben? Entweder schreib ich die Werte in der Registrierung um oder es gibt eine ADMX Vorlage, das war zumindest der Plan. (Config: Office365 und Outlook 2016, AD in Azure und onprem) Danke und Grüße Rainer

Huhu kurze Info zum Build 1803. Wir haben den gestern schon über den Business Channel eingespielt bekommen. Offiziell sind wir noch auf 1709. Frisch deployte Win10 Enterprise Maschinen mit 1709 holten sich gestern die 1803 ab, versuchten die Installation und machten dann einen Rollback zu 1709. Es bleiben aber diverse 1803 Steuerungselemente in Windows hängen. Das heißt Installation von Language Packs sind nicht mehr möglich, der Installer kommt nicht mehr klar und so einige andere Geschichten. DAbei ist 1803 noch nichtmal final...also noch beta soweit ich das sehen konnte. Seid vorsichtig mit 1803.... testen ist erstmal angesagt.... am besten erstmal Tee trinken und abwarten mit Upgrade.

Hallo Norbert danke, ticket läuft bereits. Werde berichten worans lag.

Huhu Konstellation Office365 und lokales Outlook2016. über das O365 Portal richten wir für diverse User Vollzugriff auf andere Postfächer ein (Postfachstellvertretung für Urlaubsvertretung etc.). Das Postfach erscheint dann im Outlook nach ein paar Minuten nach Outlook Neustart. Entfernt man den Vollzugriff im O365 Portal von diesen Konten bleibt das Konto als Eintrag aber im Outlook 2016 weiter sichtbar. Ich hab zwar keinen zugriff, kann die Ordnerstruktur nicht mehr erweitern, aber bei mir stapeln sich inzwischen die Postfächer links in der Postfachliste von Outlook. Ich sehe immer noch alle Postfächer, die verschwinden nicht mehr. Stellvertreter bin ich schon lange nicht mehr dafür. Per PS hab ich alle Postfachberechtigungen abgefragt, dort sind keine Stellvertretungen mehr zu sehen. Scheint also ein Bug zu sein. Weiß da jemand wie ich die Postfächer da wieder "unsichtbar" mache? Danke und Gruß

80% dieser Art von Problemen sind DNS basiert. Die DC's müssen sich sehen können und DNS muss beidseitig in beiden Netzen funktionieren. Trust wird verweigert wenn die Hostnamen bzw. die netbios namen der DC's gleich sind. (was häufig vorkommt). Normalerweise kommt beim Herstellen des Trust die Login Afbrage für den anderen Domänenadmin. Wenn der schon nicht erscheint und der RPC Fehler ausgegeben wird ist es meistens ein DNS oder Firewall Problem. DNS läuft bei unseren Trusts über bedingte Weiterleitung im DNS...

Firewall bei IPSec/IKEv2 Ports aufmachen bzw. weiterleiten. 4500, 500, 50, 51 (glaub ich für ipsec) dazu nehmen.... wenn du einen RRAS betreibst müssen die ports zu diesre IP geforwarded werden. Am Server müssen die ports auch offen sein.... sonst kommten die Verhandlungen über den Tunnel nicht zum Ende.

Hallo Nils, ist ne firmenpolitische Entscheidung, muss ich so akzeptieren. AD FS hat auch Nachteile... Das Azure hat mich gerettet. Der Gastzugriff auf die Services funktioniert auch in der Art wie wir das brauchen. Ist etwas mehr Verwaltungsaufwand aber die Funktion am Ende ist ähnlich und da wird eh jetzt fast zu 100% in der Cloud unterwegs sind passt das so. Ziel erreicht.