Marco31

Ich war auch skeptisch bezüglich der VCSA, aber ich bin auch positiv überrascht worden. Wie haben aber auch ne sehr überschaubare Umgebung (2 Hosts ohne vmotion etc). Und mit Veeam geht auch die Sicherung schnell von der Hand.

Der SQL ist bereits ein 2014er, soviel ich weiß das Maximum für SP2013. Aber um mal Licht in die Sache zu bringen, ich habe hier folgende Konstellation: Server Windows 2016 mit 1x MSSQL 2014 und 1x MSSQL2016 (auf der gleichen Maschine) installiert; auf dem 2014 läuft die SharePoint-Instanz und auf dem 2016 die Default-Instanz. Klingt jetzt zwar "etwas" exotisch, läuft aber bisher fehlerfrei und ausreichend performant. Habe auch bisher nichts gefunden dass das nicht supportet wäre. Die jetzige SharePoint Foundation 2013 läuft noch auf einem Windows 2008R2, die möchte ich auf einen Windows 2012R2 bringen. Und das teste ich gerade, die oben genannten Probleme tauchten bei der Installation der SPF 2013 auf dem neuen Win2012R2 auf.

Nein, Testumgebung ist ne 1:1 Kopie (bzw. Restore) der Echtumgebung. Daher sind die Ports schon offen, läuft ja bereits die alte SP-DB auf der Instanz. Habe aber die Lösung gefunden, mit nem SQL Alias findet er dann auch den richtigen Server mit Instanz. https://veronicageek.com/sharepoint/sharepoint-2013/configure-sql-aliases-for-sharepoint-server/2018/04/

Hallo Forengemeinde, ich muss demnächst meine SharePoint Foundation 2013 von einem W2008R2 auf einen W2012R2 verschieben. Daher bin ich in meinem Testlab gerade am testen und versuche auf dem neuen Server SP2013 zu installieren. Der SQL Server hat zwei Instanzen, die Default Instanz (MSSQLSERVER) und die Instanz SHAREPOINTSQL auf Port XY (wo ja auch bereits die DB's des alten SharePoint laufen). Das Problem ist jetzt folgendes: Wenn ich beim Konfigurationsassistenten die SHAREPOINTSQL Instanz mitgebe (sqlserver\sharepointsql), kommt der Fehler dass auf die Master DB nicht zugriffen werden kann weil der Server nicht gefunden werden kann oder die Zugriffsrechte nicht ausreichen. Die Rechte des SP-Setup-Accounts habe ich schon gecheckt, der entsprechende User hat dbcreator und securityadmin. Gehe ich mit der Installation auf die Default-Instanz gibt es kein Problem - er scheint also aus irgendeinem Grund nicht auf die SHAREPOINTSQL Instanz zugreifen zu können. Jemand ne Idee wo der Fehler liegen könnte? Wie gesagt, die Instanz fungiert bereits für den alten SP-Server als DB-Instanz. Und da gibt es auch keine Probleme.

Ok ?

Reden wir hier eigentlich von privater Spielerei oder etwas was produktiv in einer Firma, Verein oder ähnliches genutzt werden soll?

@Norbert: Kannst du das bei dir mal testen wenn du Zeit hast? Wäre schon interessant ob das ein generelles Problem ist oder mit den "Altlasten" zusammen hängt.

Weil auch dieses Forum ein gewisses Maß am Fachwissen voraussetzt. Ein Auto repariert man auch nicht mal so nebenbei wenn man nicht weiß was man tut...

Was erhoffst du dir von der Anzeige der "Größe"? Hier wird nur angezeigt was auf dem physikalischen Laufwerk des Servers insgesamt frei ist. Wenn du z.B. drei Netzlaufwerke auf einem physischen Server-Laufwerk freigibst, wird dir bei allen das gleiche als "frei" angezeigt.

Der VMware-Support hat das als "Known Issue" bestätigt, ohne SMBv1 funktioniert das derzeit nicht. Es soll in einer zukünftigen Version gefixt werden sagt der KB aus dem Januar 2019

Hattest du eventuell vergessen die FSMO-Rollen auf den neuen DC zu übertragen?

So, mal eine Rückmeldung zum eigentlichen Thema. Ich habe heute morgen die Kennwortlänge von 14 auf 20 Zeichen umgestellt. Und schon werden wieder die SceCli Fehler 1202 geloggt, net accounts /Domain zeigt weiterhin 14 Zeichen an. Ziemlich blöde...

Für mich ein typischer Fall von "Ich säge an dem Ast auf dem ich sitze"... Die Verwaltbarkeit der Clients über GPO ist eines DER Argumente für Windows Clients in der Domäne, zumal ja auch nicht erkennbar ist wie MS das sich ohne GPOs vorstellen würde. Und bis auch alle Clients in einer wie auch immer gearteten Cloud gehosted werden läuft noch sehr viel Wasser den Rhein runter. Wobei ich mir sowas nicht in meinen schlimmsten Albträumen ausmalen möchte.

Die GPO Geschichte finde ich schon nen großen Wurf, die Idee zumindest. Da möchte ich gar nicht dran denken ohne auskommen zu müssen ?

Damals waren es ja zumindest noch Features, das was heute als "Feature" verkauft wird braucht man eigentlich nicht.

Ich werde das Mitte nächster Woche testen können, ich gebe dann mal Rückmeldung. Kannst ja auch mal Rückmeldung geben wenn du das in deiner Umgebung testen konntest.

Eintragen und bestätigen konnte ich diese ja auch, nur angewendet wurden sie nicht. Da waren ja dann die SceCLi 1202 Fehler... Werde das nächste Woche mal weiter testen, vielleicht funktioniert es ja jetzt nachdem ich (wie oben in dem Artikel beschrieben) alle Einträge mal geändert und gespeichert habe...

Ähem... ich habe die Einstellungen auf einem win10 1903 Rechner gemacht... die Templates sind auch alle aktuell. Oder habe ich da was falsch verstanden?

Und wie bekomme ich meine Passwörter nun grösser 14 Zeichen? ?

Ja, auf sowas kann man verzichten Die Einstellung "RequireLogonToChangePassword" wird aber auch jetzt noch im Winlogon geloggt. Ich muss aber gestehen dass ich mich nicht so recht traue, an der GPTTMP.INF rumzufummeln... Hat jemand von euch Passwörter länger 14 Zeichen über die DPP konfiguriert oder nur über "Fine Grained Password Policy"?

Also im Eventlog bekomme ich am DC SceCli Fehler 1202, 0x57. Und das seit dem Tag an dem ich die DPP geändert habe... Das ganze hört sich so an, als seien noch Uralte Reste in der DPP die hier Probleme machen: https://superuser.com/questions/1422880/scecli-0x57-password-policy-event-1202 Tatsächlich wir der im Artikel genannte Eintrag "RequireLogonToChangePassword" im Winlogon protokolliert: ---Sicherheitsrichtlinien werden konfiguriert... Die Verabeitung der Wiederherstellungswerte für 7 Einstellungen wird gestartet. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MinimumPasswordLength>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <PasswordHistorySize>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MaximumPasswordAge>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MinimumPasswordAge>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <PasswordComplexity>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <RequireLogonToChangePassword>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ClearTextPassword>. Konfigurieren der Kennwortinformationen. Die Verabeitung der Wiederherstellungswerte für 3 Einstellungen wird gestartet. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <LockoutBadCount>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ResetLockoutCount>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <LockoutDuration>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ForceLogoffWhenHourExpire>. Konfigurieren der Informationen der erzwungenen Abmeldung. Kleine Rückmeldung: Ich habe die Anweisungen aus der ersten Antwort des Artikels ausgeführt (alle Einstellungen anwählen, ändern, speichern, wieder auf richtigen Wert setzen, speichern) und ein gpupdate /force gemacht. Siehe da, net accounts /Domain zeigt jetzt die Werte an, die auch in der DPP stehen. Habe auch die maximale Kennwortlänge auf 14 gesetzt. Aber habe ich das richtig verstanden dass man über die DPP keine Passwortlänge größer 14 setzen kann??

Ja, so ist es, da DPP und net accounts /Domain unterscheiden sich. Zu Test 1: Das sieht unauffällig aus, da steht einer meiner beiden DC's (der Betriebsmaster) drin. Zu Test 2: Wo muss ich da genau hinschauen? Mit adsiedit bin ich jetzt nicht so wirklich vertraut. Weitere Probleme gibt es keine, zumindest keine die mir aufgefallen sind.

Folgendes ist definiert: RSoP sagt genau das was auch in der DPP definiert ist. Und hier nochmal net accounts /Domain:

Guten Morgen Also auf Root-Ebene sind ausser der DDP noch 8 weitere GPO's definiert, aber keine davon hat Kennwortrichtlinien definiert. Zweimal Terminalserver (Anmelden über Terminaldienste zulassen & SSO), zweimal Zertifikat-Verteilung, einmal Einstellung TimeService, zweimal SMBv1 Disable, einmal Logon as Batch Job. Alle aktiv auf Root Ebene.

Ok.... Da stehen die falschen (alten) Einstellungen drin.... Wie kann das denn sein?