[Gelöst] Anmeldung an MS SQL Server von Windows-Service aus scheitert

Guten Tag zusammen,

ich habe einen MS SQL Server (2016) auf dem ich mehrere DBs habe.
Auf dem Server existiert eine Anmeldung "mailService" welche in der DB einen entsprechenden User hat.

Die Verbindung sieht wie folgt aus:

        private readonly IDbConnection dbMails = new SqlConnection("user id=mailService; password=password1234;Server=192.168.2.21,1433\\FILESERVER; database=Mails;");

Üblicherweise ist der Connection-String natürlich nicht hardcoded, dies habe ich nur in Folge des Debuggings geändert.

Ich habe nun einen Windows-Service erstellt und installiert, wobei dieser folgende Fehlermeldung wirft sobald er versucht den Server zu erreichen:> Fehlermeldung:

Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: TCP Provider, error: 0 - Ein ungültiges Argument wurde angegeben.)

Wenn ich statt der IP einen Domainname verwende kommt die gleiche Meldung allerdings statt "falschem Argument" folgendes:> Fehlermeldung:

Beim Datenbankaufruf ist ein nicht behebbarer Fehler aufgetreten.

Testweise habe bin ich folgende Dinge durchgegangen:*Ich habe die Verbindung in einer Konsolenanwendung im Debugger geöffnet -> keine Probleme *Ich habe mich an einer anderen Maschine mit dem (Windows-)User, den der Service verwendet angemeldet und mich dann über das MSSQL Studio mit der SQL-Anmeldung des Services angemeldet -> keine Probleme *Zudem läuft auf der Maschine auf der der Service installiert wurde bereits ein weiterer Service, der im Prinzip die gleiche Verbindung verwendet (copy&paste nur mit anderen Credentials und anderer DB) -> ohne Probleme
Also eigentlich sollte die Umgebung kein Problem darstellen (alle Configs und Libraries korrekt und vorhanden).

*Den zweiten Service habe ich auch testweise deaktiviert um auszuschließen, dass die beiden sich, warum auch immer, gegenseitig behaken. *Just in case hab ich die betroffene Maschine auch neugestartet

Die Fehlermeldung deutet ja auf ein spezifisches Problem mit dem Connection-String hin, allerdings dürfte in dem Fall die Anmeldung in der Konsolenanwendung ebenfalls nicht funktionieren.

Ich hab leider mittlerweile keine Ideen mehr wo ich nach dem Fehler suchen kann. Ich bin für Tips und Anregungen dankbar..

Beste Grüße
emuuu

Ist das Komma zwischen Hostname und Port nur im Forum ein Schreibfehler oder hast du das auch im echten ConnectionString?

Edit:
@Abt Danke. Wieder etwas gelernt.

Die Fehlermeldung sagt deutlich, dass keine Verbindung aufgebaut werden konnte.
Sieht nun also nach Firewall aus oder andere Gründe, wieso die Maschine keinen Zugriff erhält.

@danooe, der Port ist so richtig angegeben. Da muss ein Komma hin.

Sieht nun also nach Firewall aus oder andere Gründe, wieso die Maschine keinen Zugriff erhält.

Mir ist schon klar, dass der Verbindungsaufbau das Problem ist. Ich weiß nur keine Möglichkeit mehr wo dieses Verortet sein kann:

Zudem läuft auf der Maschine auf der der Service installiert wurde bereits ein weiterer Service, der im Prinzip die gleiche Verbindung verwendet (copy&paste nur mit anderen Credentials und anderer DB)

Der zweite Service ist absolut identisch aufgesetzt, nur die Crendentials und die Anmeldung sind unterschiedlich. Ein fehlende Firewall-Einstellung, müsste dann doch beide Services an einer Verbindung hindern oder?

Das ist der Hauptgrund, warum ich nicht nicht mehr weiter weiß: Jeder Grund der mir einfällt, bzw. den ich ergoogled habe müsste beide Services behindern und nicht nur den neuen.

Es ist in Deiner Beschreibung nicht ersichtlich, wie viele Rechner oder Netzwerkteilnehmer überhaupt involviert sind; von wo aus Du zugreifst.

Ok, sorry. Vielleicht ist es so ersichtlicher:

**Rechner A (192.168.2.21)***MS SQL Server

**Rechner B (192.168.2.22)***Service A -> Zugriff funktioniert *Service B -> Zugriff funktioniert nicht

**Rechner C (Entwicklungsumgebung / 192.168.2.23)***Konsolenanwendung -> Zugriff funktioniert

Service A*Windows-User: innerFileService *Connection-String: ("user id=fileService; password=password1234;Server=192.168.2.21,1433\FILESERVER; database=FmUnit2;");

Service B*Windows-User: innerMailService *Connection-String: ("user id=mailService; password=password1234;Server=192.168.2.21,1433\FILESERVER; database=Mails;");

Beide Windows-User sind vom gleichen User vererbt

Konsolenanwendung*Windows-User: dev *Connection-String: ("user id=mailService; password=password1234;Server=192.168.2.21,1433\FILESERVER; database=Mails;");

Was sich mir wirklich nicht erschließt ist eben der Punkt:
Wenn der Connection-String das Problem ist, dürften die Konsolenanwendung und Service B nicht laufen.
Wenn die Umgebung auf Rechner B das Problem ist (Firewall, Rechte), dürften Service A und B nicht laufen.
Es läuft aber jeweils nur Service B nicht.

Und worin unterscheiden sich die Services vom Aufbau oder Hosting oder Berechtigungen?
Firewalls können schon so eingestellt sein, dass sie auf Prozess-Ebene funktionieren und nicht auf IP/Port/Typ..

Es sind beides Windows-Dienste (die Installer-Parameter sind identisch), welche beide automatisch nach dem Systemstart gestartet werden.

Der Aufbau ist bei beiden identisch:

        protected async override void OnStart(string[] args)
        {
            await InitMailService();
//bzw.
            await InitFileService();
        }

Beide Inits() beginnen mit einer Abfrage an ihre jeweilige DB (FmUnit2 bzw Mails / auf dem gleichen Server). Service A läuft hier ohne Probleme während Service B eben in eine catch(Exception) mit besagter Meldung läuft.

Die Windows-User die die Services verwenden sind vom selben User vererbt und haben nur im Dateisystem gesonderte Lese-/Schreibrechte.

Edit:
Nach Erstellung des ersten Dienstes mussten keine Firewall-Änderungen vorgenommen werden.

Update:
Ist gelöst. War irgend ein clusterfuck mit der activeDirectory, den ich bis jetzt noch nicht nachvollziehen kann. Neuerstellung der Windows-User hat das Problem gelöst.