Results for tag "server"

3 Articles

WSUS: Moving from Windows Internal Database to external SQL Server 2008 and receiving “Token-based server access validation failed with an infrastructure error”

Today I had to move the WSUS internal database to one of our backend database servers. Microsoft has a good instruction how to do this, nevertheless I ran into a problem.

Microsoft SQL Server 2008 did not allow me to add the machine account of our WSUS frontend server (let me call it WSUS-SRV), so I created a new Active Directory security group called WSUS Administrators containing the WSUS-SRV machine account. This security group I gave the permission to access the database.

After starting the IIS Admin Service and Update Services the database backend server showed the error Token-based server access validation failed with an infrastructure error (event-id 18456). Oops.
One workaround  would have been to disable the UAC (http://blogs.msdn.com/b/sqlserverfaq/archive/2010/10/27/troubleshooting-specific-login-failed-error-messages.aspx). Not a solution I was very keen about.

I fixed the problem by creating a local security group on the database server and adding the maching account of WSUS-SRV into it.

Remove version signature from TeamCity, Confluence and JIRA

If you want to make your TeamCity, Confuence or JIRA instance accessible from outside of your LAN, you should remove all version signatures so that no attacker can easily lookup for existing exploits.

  • TeamCity: Open <TeamCity installation dir>/webapps/ROOT/WEB-INF/tags/version.tag and remove the full content from this file. You must restart the TeamCity service afterwards.
  • Confluence: Open <Confluence installation dir>/confluence/decorators/includes/footer-content.vm and remove the line
    <li class=”print-only”>$action.getText(‘printed.by.atlassian.confluence’,[“$generalUtil.versionNumber”])</li>Restart of Confluence service/instance is required.
  • JIRA: Open <JIRA installation dir>/atlassian-jira/WEB-INF/classes/templates/plugins/footer/footer.vm and remove the line
    <span id=”footer-build-information”>(v${build.version}#${build.currentBuildNumber}${commitId}${partnerName})</span>

    Restart of JIRA service/instance is required.

Gelöst: Encoding-Probleme mit MS SQL und PHP

Seit letzter Woche habe ich mich mit einem äußerst ominösen Problem beschäftigt – wär ja sonst auch langweilig: Ich habe für einen Kunden ein Import-Script geschrieben, dass aus mehreren Text-Dateien die Daten in eine MS SQL Server 2005-Datenbank importiert.
Bei unseren Tests hier in der Firma funktionierte alles wunderbar, es gab keine UTF-8- oder sonstigen Zeichensatz-Probleme – die Umlaute wurden korrekt dargestellt.

Nun meldete sich der Kunde und teilte uns mit, dass die Umlaute falsch dargestellt wären. Aus einem “für” wurde ein “fnr” u.s.w. Ein Schelm, wer jetzt denkt, es würde an UTF-8 liegen. Daran lag es nämlich nicht.

Der Kunde setzte einen amerikanischen Windows Server 2003 und ebenfalls einen amerikanischen Microsoft SQL Server 2005 ein – wir hingegen hatten die jeweils deutschen Versionen eingesetzt. Lag es an den unterschiedlichen Länder-Einstellungen? Nein, daran lag es nicht – wie wir nach dem Aufsetzen der gleichen Maschine feststellten.

UTF-8-Probleme auf Seiten PHP konnte ich ebenfalls ausschließen, da sonst substr() aus dem “für” ein “fn” hätte machen sollen.

Über die Lösung des Problems bin ich mehr durch Zufall gestolpert: Das Tool cliconfig.exe (zu finden unter %WINDOWS%system32) bietet unter dem Tab DB-Library Options die Option Automatic ANSI to OEM conversion. Auf unseren System war diese Option deaktiviert, beim Kunden hingegen aktiviert. Warum? Ganz einfach: die Datenbank beim Kunden lief vor einigen Monaten noch unter MS SQL Server 2000 und wurde dann auf SQL Server 2005 geupgradet. Die Standard-Einstellungen für o.g. hatten sich vom Versions-Wechsel anscheinend geändert und somit konnten wir eben nicht die exakt gleichen Bedingungen nachstellen.

Was für ein Gefrickel, aber: Wieder ein Problem weniger auf der Welt.

Update: Ganz wichtig in diesem Zusammenhang ist, dass das Umlautproblem nur auftritt, wenn das PHP-Script von der Kommandozeile aufgerufen wird. Der Aufruf des Scripts als ausgeführtes CGI-Script in einer Apache-/IIS-/…-Umgebung liefert die richtigen Resultate.