Jump to content

phoefliger_bytelink

Members
  • Gesamte Inhalte

    19
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von phoefliger_bytelink

  1. Uns fällt gerade auf das beim Installationscenter => Editionsupgrade keine Instanzen gefunden werden `? Die Lizenz ist von einem abgelösten Serversystem ca. 15 Monate alt...
  2. Hallo zusammen, Wir versuchen seit 2 Tagen ein SQL Server 2016 Eval auf Standard zu lizenzieren. Der Setup läuft sauber durch und erkennt auch den Lizenzschlüssel als Standard. jedoch wird nach dem Setup nur der SQL Browser als korrekt lizenziert angezeigt, der SQL Server selber meldet immer noch Eval x64. Habt Ihr da einen Tipp? Danke
  3. Ich frag mal so in die Runde der SQL Spezialisten - macht es Sinn den SQL Server Agent User direkt explizit auf dem Filesystem zu berechtigen - also nicht wie sonst verschachtelt in Globale und dann DL Gruppen?
  4. Wie gesagt wir haben eine Testfreigabe erstellt und die Share & NTFS Berechtigungen neu vergeben. Wenn wir den SQL Agent Benutzer direkt auf NTFS gewähren dann funktioniert es - ersetzten wir den User mit der Domänen lokalen Gruppe welcher unter anderem auch den SQL Agent Benutzer beinhaltet dann geht es nicht mehr. Also explizit berechtigt geht - als Mitglied der Gruppe geht nicht...
  5. Okay sind ein wenig weiter gekommen... Wir haben eine neue Freigabe erstellt und die Berechtigungen ein wenig angepasst und getestet... Folgendes Szenario... Wird der SQL Agent User ( sqlau@domain.local ) direkt auf NTFS Ebene Berechtigt (Order Import) dann funktioniert der Bulk Insert bzw. der Zugriff auf die Datei - sobald der Benutzer in der Domain Local Group (oder auch Global geht beides nicht) sich befindet so wird der Zugriff verweigert. Was übersehe ich da ? Grüsse
  6. Hallo Sunny, ja liegt im Netzwerk - wird jedoch direkt über UNC Pfad angesprochen.
  7. Hallo zusammen, Ich hätte da man eine Frage bezüglich SQL 2016. Wir haben bei einem Kunden eine neue IT Infrastruktur bereitgestellt. Einer der Softwarehersteller hat dementsprechend deren Applikation implementiert. Der Hersteller meldet jetzt, dass die TSQL Scripts zwar ablaufen jedoch mit Fehlern kollidieren. Fehlermeldung: Massenladen nicht möglich da die Datei, xxx nicht geöffnet werden konnte. Betriebssystemfehlercode: 5 (Zugriff verweigert) Der SQL Agent läuft unter einem Domänenkonto (Berechtigungen etc. sind gesetzt sowie lokale Benutzerrichtlinien kontrolliert). Im ersten Schritt habe ich ein TSQL Script erstellt welches simpel eine Datei in dem besagten Verzeichnis anlegt und beim nächsten Zyklus wieder löscht - das ganze alle 5 Minuten. Der Task hat keine Probleme die Datei zu erstellen/löschen. Ausgeführt wird dies mit dem SQLAgent Benutzer. Ich bin absolut kein SQL Spezialist und ich dachte eigentlich, dass die Hersteller/Entwickler da einen Plan haben wie was aufgesetzt werden muss. Danke
  8. Hallo Nils, Anbei den Veeam Artikel für die Verwendung: https://www.veeam.com/kb2194 Falls du natürlich eine andere Möglichkeit siehst oder kennst, wäre ich Dir dankbar für Infos. Grüsse Pascal
  9. Hallo Nils, die Veeam Snapshots werden langsam zu gross für das aktuelle Storage und dementsprechend möchten wir den Snapshotpfad auf ein andere Ressource (anderes Storage) umbiegen. Die initiale Konfiguration des ConfigStoreRootPath muss somit angepasst werden - jedoch verweigert der Cluster die Änderung des Pfades über PowerShell. Laut MS ein Designfehler welcher irgendwann behoben werden soll. Workaround ist die ClusterDB in die Registry zu laden sowie den Clusterservice Dienst vorab zu beenden dann einen Node updaten und alles wieder hochfahren - ich dachte einer von den Spezialisten hat da vielleicht eine bessere Variante... Grüsse Pascal
  10. Dies funktioniert bei der Initial Konfiguration jedoch besteht keine Möglichkeit diesen danach zu ändern. bzw. sobald dieser einmal gesetzt wurde meldet der Cluster über Powershell unzulässiger Befehl. Ich erinnere mich, dass MS by Design diesen Fehler in 2017 schon hatte - aber dass immer noch kein Hotfix bestehen soll ist verwunderlich gerade bei einem Failover Cluster sollten die Funktionen schon stabil und sauber einsetzbar sein. Das Workarround mit Clusterservice beendet auf allen Nodes dann die Registry der ClusterDB zu laden und dort drin Anpassungen zu machen finde ich auf einer produktiven Umgebung mehr als eine Zumutung.
  11. Hallo zusammen, Ich hätte da mal eine Frage an die Leute welche einen Failover Cluster Server2016 im Betrieb haben. Wir wollten in einer produktiven Umgebung den ConfigStorePath auf ein anderes Laufwerk legen - jedoch ist dies scheinbar nicht möglich laut MS Forum. Der Workarround ist relativ mühsam mit Clusterservice beenden und Load Hive etc. Da bin ich eigentlich kein Fan dies an einem Livesystem durchzuspielen. Kennt jemand von Euch eine "saubere" Methode ohne gleich den Cluster zu stoppen? Danke Euch...
  12. Hallo zusammen, Wir planen gerade für einen Kunden eine "kleine VDI" Umgebung um von Remote arbeiten zu können. Jetzt meine Verständnisinnige: Ich habe alle Microsoft Papers durch finde aber keine wirkliche oder nur "schwammige" Lösung. Wir setzten einen 2016 Failovercluster mit 2 Nodes und 4x 10GB/s ISCSI SAN ein und würde gerne den VDI Pool auf dem Cluster betreiben. Ist dies grundsätzlich möglich? Sinn und Zwecke wäre die VDI Clients auch hoch verfügbar auszulegen. Grüsse und Danke für Euren Input
  13. danke Dir - falls jemand noch was einfällt einfach schreiben.
  14. Danke kenne ich - die Problematik ist, dass die Symptome nicht immer auftreten. Es scheint mir also würde die Problematik auftauchen sobald neue Sessions aufgebaut werden müssen. Also Idle Timeout erreicht ist. Beispiel wenn das PC System sich richtig angemeldet hat und ein Neustart vollzogen wird - so läuft meistens der Startup Prozess sauber durch dementsprechende NBSS Continuations ersichtlich. Kerberos Problematik könnte ein Grund sein - sehe aber eigentlich auch diesen sauber durchlaufen ... Ich werde mal am Montag den Switch wechseln und 2-3 Clients direkt aufschalten also nicht über Patchpanel - wo möglich gibt dies eine Besserung. Ich sehe aber ehrlich gesagt praktisch keine Discards auf den Netzwerkanschlüssen was mich an einem Layer1 Problem zweifeln lassen.
  15. den vermisst du weil ausser dem Eventlog Fehler (1054) auf dem Server welcher im ersten Eintrag erwähnt wurde keine ersichtlich sind...
  16. Hallo Tektronix, Sysvol-Verzeichnis sieht soweit okay aus. GP Result gibt die korrekten Informationen aus. GPO's wurden beim Testclient umgangen (eigene OU auf root Ebene) es wirken also dort nur die Def.Dom.Pol
  17. Hallo Norbert, DNS ist soweit auf den Clients sowie Server konfiguriert bzw. eingetragen - DNS Forwarding auf DNS Server konfiguriert. Wie oben geschrieben funktioniert der Kommunikationsteil beim starten - DHCP Acks vorhanden DNS request auf SRV ldap erfolgreich aufgelöst. Auch wenn die Verbindung zum Share nicht aufgebaut werden kann - funktionierte die Namensauflösung. Ich denke die Problematik ist eher im Bereich SMB zu finden. Grüsse Pascal Hallo Sebastin, Nein es ist nur der Server drin - DNS forwarding wird über den DNS Server gemacht.
  18. Hallo Sebastian, IP Einstellungen werden per DHCP von dem SBS2011 Server vergeben. Wireshark Logs zeigen eine saubere DORA Verarbeitung. Auf dem Test Client wurden die Einstellungen für einen Test auch fixiert jedoch keine Besserung. Gruss Pascal
  19. Hallo zusammen, Ich habe aktuell ein bisschen mühsames Problem bei einem Kunden. Beim Kunden läuft noch ein SBS2011 Server und wir haben die Clients durch neue aktuelle Modelle mit Win7 Pro ersetzt. Ausgangslage: 1x HP ML350 G6 - Serversystem mit SBS2011 - Domaincontroller 20x Clients ProDesk400 G4 - Windows 7 Pro 1x Switch HP 1910/48G (flach keine Trunks/Taggings) Jetzt meldet der Kunden vermehrt folgendes Verhalten: - PC Systeme benötigen lange beim Startprozess (Bitte warten... und auch später beim Logon) - Weiter können die Clients ab und zu nicht auf die \\Domain Verknüpfung zugreifen - Explorer hängt und nach dem 2ten Versuch klappt es meistens wieder. - Das gleiche Verhalten beim Server mit Eventlogeintrag Grouppolicy 1058 Folgendes wurde unternommen/getestet: - DCDIAG ist sauber - DNS Auflösung gemäss Wireshark sauber System findet alle SRV Einträge und werden auch beantwortet - Patchkabel gewechselt auf Kat.6 - Neues PC System (test) integriert mit neuem AD Benutzer - Computer und Benutzerkonto alle GPO's deaktiviert - Ipv6 ein/aus - LAN Adapter Treiber downgrade/upgrade - Aus der Domäne neu in die Domäne - Switch kaskadiert ( Link Layer1 immer Up) brachte nichts *Vermutung LAN Adapter zu schnell bzw. Switch zu langsam - Komisch wäre noch das die SMB Sessions zum Teil seit 20 Tagen im Session Manager ersichtlich sind - bei net session /delete werden diese dann aber nicht gefunden. - SMBv1 deaktiviert - kurzzeitig SMBv2 deaktiviert - Netbios over TCP/IP deaktiviert/aktiviert Mittels Wireshark folgende Informationen - PC System hängt beim Bootprozess bei SMB Negoziation Request sendet dann ein paar TCP Pakete wartet dann wieder - DNS Request werden alle beantwortet - Smb negotiate protocol request ersichtlich vielmals aber kein Response Als nächstes würde ich den Switch wechseln - jedoch bin ich mir da ein bisschen unsicher da ja auch der Server Probleme mit SMB auf seinen eigenen Shares hat. Für Tipps bin ich dankbar...
×
×
  • Neu erstellen...