Icon Makefg

Migration einer Installation von NoSpamProxy Version 10.x und 11.x

Um die Version 10.x und 11.x auf einen anderen Rechner zu verschieben, gehen Sie wie folgt vor:

  1. Kopieren Sie die Intranet Role.config und die die license.xml auf den neuen Computer.
  2. Legen Sie das Verzeichnis “C:\ProgramData\Net at Work Mail Gateway\Configuration” an und kopieren Sie Intranet Role.config  und license.xml hinein.
  3. Passen Sie die Intranet Role.config an.
  4. Installieren Sie den SQL-Server.
  5. a) Sichern Sie die Datenbankdateien und stellen Sie auf dem Ziel-SQL-Server wieder her ODER
    b)Verschieben Sie die Datenbankdateien in das neue Verzeichnis und hängen Sie diese in den SQL-Server ein.
  6. Führen Sie das NoSpamProxy Setup aus.
  7. Verbinden Sie die Intranetrolle mit der Gatewayrolle.
  8. Kontrollieren Sie anschließend alle vormals gesetzten Passwörter sowie Zertifikate und ordnen die Konnektoren neu zu.

Die Schritte im Detail

  1. Kopieren Sie die Intranet Role.config und die license.xml​ auf den neuen Computer.
    Zuerst halten Sie auf dem Quellcomputer die NoSpamProxy-Dienste und anschließend die SQL-Datenbankinstanz an. Diese finden Sie unter den Windows-Diensten üblicherweise als “SQL Server (NOSPAMPROXY)”. Stoppen Sie dann anschließend alle Net at Work Mail Gateway-Dienste.
    Kopieren Sie die Intranet Role.config und license.xml aus “C:\ProgramData\Net at Work Mail Gateway\Configuration” auf den Zielcomputer.
    Bitte kopieren Sie NUR die genannten Dateien aus den Verzeichnissen, da es sonst zu Problemen bei der Installation kommen könnte.
  2. Legen Sie das Verzeichnis “C:\ProgramData\Net at Work Mail Gateway\Configuration” an und kopieren Sie Intranet Role.config  und license.xml hinein.
  3. Passen Sie die Intranet Role.config an.
    Öffnen Sie die Datei mit einem Editor, beispielsweise Notepad, und suchen Sie nach folgendem Eintrag:
    <connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
    <EncryptedData>
    <CipherData>
    <CipherValue>AQAAANCMnd...==</CipherValue>
    </CipherData>
    </EncryptedData>
    </connectionStrings>

    Verändern Sie diesen so, dass dieser am Schluss wie folgt aussieht:
    <connectionStrings>
    </connectionStrings>

    Suchen Sie in der ganzen Datei nach
    encryptedPassword=
    und änderen Sie die Vorkommen, die so ähnlich aussehen wie
    encryptedPassword="AQAAANCM...W9b17"
    in
    encryptedPassword=""
    Gehen Sie analog für alle Vorkommen von
    tlsCertificatePin="AQAAANCM...W9b17"
    und
    tlsCertificateThumbprint="AQAAANCM...W9b17"
    sowie
    password="AQAAANCM...W9b17"
    und
    privateKey="AQAAANCM...W9b17"
    vor.Speichern Sie nun die Datei ab.
  4. Installieren Sie den SQL-Server.
    Installieren Sie nun den SQL-Server in der von Ihnen gewünschten Version ab SQL Server 2008. Vergessen Sie nicht die Verwaltungstools, insbesondere das SQL Management Studio zu installieren.
  5. a) Sichern Sie die Datenbankdateien und stellen Sie auf dem Ziel-SQL-Server wieder her
    Mit Hilfe des SQL Management Studios erstellen Sie zunächst eine Sicherung der SQL-Datenbank “NoSpamProxyAddressSynchronization” auf dem Quell-Server. Klicken Sie dazu die genannte Datenbank mit der rechten Maustaste an und wählen “Task / Backup” aus. Es öffnet sich ein Dialog. Dort belassen Sie alles beim Standard und führen im unteren Abschnitt lediglich eine “Disk” und den entsprechenden Pfad der Sicherungsdatei hinzu. Starten Sie anschließend die Sicherung. Die entstandene Sicherungsdatei kopieren Sie anschließend auf den Ziel-Server und führen eine Wiederherstellung durch.
    ​Klicken Sie dazu im SQL Management Studio des Ziel-Servers mit der rechten Maustaste auf “Databases” und wählen “Restore Database” aus. Es öffnet sich ein Dialog.​
    Dort wählen Sie zunächst “Device” aus und fügen in dem nun erscheinenden Dialog ein neues “File” hinzu. Dieses File ist die gerade kopierte Sicherungsdatei.​ Starten Sie nun die Wiederherstellung.b) Verschieben Sie die Datenbankdateien in das neue Verzeichnis und hängen Sie diese in den SQL-Server ein.
    Die SQL-Datenbankdateien liegen üblicherweise im Pfad “C:\Program Files (x86)\Microsoft SQL Server\MSSQL.XXXX\MSSQL\Data” oder “C:\Program Files\Microsoft SQL Server\MSSQL.XXXX\MSSQL\Data”. Sie erkennen Sie an dem Namen, der mit NoSpamProxy beginnt. Kopieren Sie sowohl die NoSpamProxyAddressSynchronization.mdf als auch NoSpamProxyAddressSynchronization.ldf-Datei auf den Zielcomputer.
    Verschieben Sie nun die Datenbankdateien in das gewünschte Verzeichnis. Dies muss nicht zwingend das Standardverzeichnis des SQL-Servers sein. Öffnen Sie anschließend das SQL Management Studio. Nach der Anmeldung am Server klicken Sie rechts auf Datenbanken und wählen Anfügen (bzw. Databases und Attach) aus. Im folgenden Dialog fügen Sie die erste Datenbankdatei aus dem gewünschten Verzeichnis hinzu. Die zugehörige Logdatei wird automatisch erkannt.
  6. Führen Sie das NoSpamProxy Setup aus.
    Starten Sie nun das Setup des NoSpamProxy. Wählen Sie UNBEDINGT die Advanced Installation aus.
    Bei der Abfrage, welcher SQL Server genutzt wird, wählen Sie aus, dass bereits ein SQL Server installiert ist und stellen die entsprechenden Verbindungsparameter ein. Das Setup erkennt dann alle weiteren Konfigurationsdateien und passt diese an.
  7. Verbinden Sie die Intranetrolle mit der Gatewayrolle.
    Sobald das Setup erfolgreich durchgelaufen ist, verbinden Sie die Intranetrolle unter dem Punkt Gateway Komponenten neu mit der Gatewayrolle und ggf. dem Webportal. Löschen Sie hierzu die bereits bestehenden Verbindungen, starten Sie danach die Intranetrolle neu und verbinden diese neu.
  8. Kontrollieren Sie anschließend alle vormals gesetzten Passwörter sowie Zertifikate und ordnen die Konnektoren neu zu.
    Mit der Umstellung wurden die geräteabhängig-verschlüsselten Passwörter gelöscht bzw. sind nicht mehr entschlüsselbar. Dies gilt insbesondere für das Passwort zum Schutz sensibler Daten, mit dem die privaten Schlüssel von S/MIME und PGP geschützt werden. Setzen Sie in der Oberfläche das alte Passwort erneut, um den Zugriff wiederherzustellen.Gleiches gilt für ggf. im Empfangskonnektor konfigurierte SSL-Zertifikate. Kontrollieren Sie daher alle Passwörter und SSL-Zertifikate, die zuvor hinterlegt waren und setzen Sie diese neu.
    Außerdem müssen die Sende- und Empfangskonnektoren wieder entsprechenden Gatewayrollen zugewiesen werden.

Hinweis
Die Gatewayrolle und das Webportal beziehen alle Informationen von der Intranetrolle. Daher werden diese bei einer anstehenden Migration einfach neu installiert.

Icon Makefg

Wichtige Informationen zum Einbinden von SwissSign als Zertifikatsanbieter

Das folgende Dokument ist gemeinsam mit unseren Kollegen von SwissSign entstanden. Es führt alle Punkte auf, die es beim Einbinden einer Managed PKI von SwissSign in NoSpamProxy zu beachten gilt.

FAQNetAtWork.pdf

Dieses Dokument wird bei Bedarf aktualisiert.

Letzte Aktualisierung: 03.09.2015

Von NoSpamProxy unterstützte SwissSign Silver-ID-Produkte

NoSpamProxy unterstützt aktuell zwei von drei angebotenen Silver-ID-Produkten:

  • Silver-Zertifikate ohne State-, Organisations- und Landes-Feld
    • Name im Bestellprozess: E-Mail ID Silver, E-Mail-Adresse validiert (Weboberfläche oder Partnerapplikation)
    • Produktname im NoSpamProxy: <<Firmenbezeichnung>>-perso-silver-emailonly
    • Ab NoSpamProxy Version: 13.2.21230.1449
      Fehlermeldung vor dieser Version: Unconsumed SDN (i.e.: SDN attributes not needed and not utilized; please remove them and resubmit your request): o=[…]
  • Silver-Zertifikate ohne State-Feld
    • Name im Bestellprozess: E-Mail ID Silver, E-Mail-Adresse validiert, Organisation, Land (nur Partnerapplikation)
    • Produktname im NoSpamProxy: <<Firmenbezeichnung>>-perso-silver
    • Ab NoSpamProxy Version: 13.2.21111.1701
      Fehlermeldung vor dieser Version: Unconsumed SDN (i.e.: SDN attributes not needed and not utilized; please remove them and resubmit your request): state=[…]

Nicht unterstützte Produkte

Das folgende Silver-ID-Produkt wird nicht unterstützt:

  • Silver-Zertifikate mit State-Feld
    • Name im Bestellprozess: E-Mail ID Silver, E-Mail-Adresse validiert, Organisation, Kanton/Bundesland, Land (nur Partnerapplikation)

Bitte beachten Sie dies im Beschaffungsprozess bei SwissSign und bestellen Sie nur die unterstützten Produkte!

Sollten Sie das falsche Produkt bestellt haben, finden Sie unter folgendem Link das Formular, mit dem Sie die Änderung bei SwissSign beantragen können:
https://www.swisssign.com/dam/jcr:85abf68a-1990-47f7-9530-9b1cce0397a7/MPKI_ChangeOrder_DE.pdf

 

Information in Verbindung mit SwissSign Gold Produkten

Wenn Zertifikate für allgemeine oder Systempostfächer angefordert werden sollen, muss dem Anzeigenamen (allgemeiner Name (Common Name, CN)) ein Pseudo: davor gesetzt werden. Dies kann nicht durch den NoSpamProxy automatisiert davor gesetzt werden, sodass diese Information mit aus dem Active Directory oder LDAP kommen. Dabei muss diese Information als erstes stehen, somit idealerweise als Vorname geliefert werden.

Um die richtige Reihenfolge im CN zu übermitteln, verwenden Sie bitte die NoSpamProxy Version 13.2.21111.1701 oder höher

 

Icon Makefg

Konfiguration eines Webproxy für NoSpamProxy ab Version 9.2

Dieser Artikel beschreibt, wie Sie ab der Version 9.x des NoSpamProxy einen Proxyserver konfigurieren. Der Cyren-Filter und Antivirus arbeitet ebenfalls über Port 80, dieser wird jedoch separat konfiguriert: Konfiguration CYREN Premium AntiVirus

Abfragen über Windows-Komponenten

Damit auch Abfragen, die über Windows-Komponenten direkt erfolgen, wie z.B. eine etwaige Zertifikats-Sperrlisten-Prüfungen (CRL), über den Proxy erfolgen können, müssen Sie diesen noch generell im System hinterlegen. Hierzu führen Sie folgenden Befehl als Administrator aus, der die Proxy-Einstellungen aus dem Internet Explorer für die Systemkomponenten übernimmt:

netsh winhttp import proxy source=ie

Die ist notwendig auf dem Server mit der Intranet- und Gatewayrolle vom NoSpamProxy.

Gatewayrolle

Um den Proxy einzutragen muss die Datei NetatworkMailGatewayGatewayRole.exe.config aus dem Verzeichnis “..\Net at Work Mail Gateway\Gateway Role” editiert werden. Die folgenden Zeilen müssen hinzugefügt werden.
Copy&Paste funktioniert nicht, da unsichtbare Steuerzeichen mitkopiert werden.

<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://192.168.1.10:3128"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>

Passen Sie die IP-Adresse Ihres Proxy-Servers entsprechend an. Die Datei muss dann ungefähr wie folgt aussehen. Bitte editieren Sie jedoch eine Kopie der Original-Datei!
Copy&Paste funktioniert nicht, da unsichtbare Steuerzeichen mitkopiert werden.

<?XML version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<gcServer enabled="true" />
<generatePublisherEvidence enabled="false"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.2.0" newVersion="5.6.2.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Services.Client" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://192.168.1.10:3128"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>​​
</configuration>

Falls Sie Ausnahmen definieren möchten, fügen Sie noch folgenden Abschnitt direkt über der Zeile </defaultProxy> hinzu:

<bypasslist>
<add address="[a-z]+\.contoso\.com$" />
<add address="192\.168\.\d{1,3}\.\d{1,3}" />
<add address="intranet.nospamproxy.de" />
</bypasslist>​

Falls es zwingend notwendig ist, zu sagen, dass KEIN Webproxy benutzt werden soll, muss folgendes eingetragen werden:

<system.net>
<defaultProxy enabled="false" />
</system.net>

Nachdem Sie die Datei angepasst haben, muss die Gatewayrolle neu gestartet werden.

Beachten Sie bitte weiterhin, dass mit jedem Patch/Upgrade die Datei überschrieben werden kann und die Änderungen erneut durchgeführt werden müssen.

Intranetrolle

Möchten Sie der Intranetrolle einen Proxy zuweisen, geht dies analog zur obigen Beschreibung über die NetatworkMailGatewayIntranetRole.exe.config aus dem Verzeichnis “..\Net at Work Mail Gateway\Intranet Role”. Beachten Sie bitte, dass die Intranetrolle eine direkte Kommunikation zur Gatewayrolle benötigt. Definieren Sie daher Proxyausnahmen für die Gatewayrolle(n).

Outlook AddIn

Falls ein WebProxy mit Authentifizierung auf dem Client PC verwendet wird kann es vorkommen, dass das NoSpamProxy Outlook AddIn keine Dateien auf das WebPortal vom Client PC hochladen kann, da hier die Informationen aus den Systemvariablen nicht greifen. Um diese Informationen dem AddIn aber zur Verfügung stellen zu können müssen Sie folgende Schritte durchführen:

    1. Im Installationsverzeichnis von Microsoft Outlook muss eine neue Datei mit Namen “Outlook.exe.config” neben die Datei “Outlook.exe” erstellt werden.
    2. Diese Datei muss nun mit folgenden Informationen gefüllt und abgespeichert werden
      <configuration>
      <system.net>
      <defaultProxy useDefaultCredentials="true" />
      </system.net>
      </configuration>
    3. Outlook neu starten

Weitere Informationen hierzu finden Sie auf dieser Microsoft Seite .

Icon Makefg

SSL Zertifikat für den Zugriff auf die Disclaimer Seite ändern

Wenn Sie ein spezielles eigenes SSL-Zertifikat zur Absicherung der Management Webseite des Disclaimer-Tools nutzen möchten, so ist dies problemlos möglich. Hierzu muss das gewünschte Zertifikat mit dem privaten Schlüssel im Zertifikatsspeicher des Computerkontos auf der Intranetrolle unter “Eigene Zertifikate” hinterlegt sein. Im Trainingsvideo zum Einbinden eines eigenen TLS-Zertifikats wird dies unter anderem für die Gatewayrolle erklärt. Die manuelle Rechteanpassung für die Intranetrolle ist jedoch nicht notwendig, dies wird vom folgenden Powershell-Kommando für Sie erledigt.

Wenn das Zertifikat sich im Zertifikatsspeicher auf der Intranetrolle befindet, führen Sie auf dieser als lokaler Administrator eine mit Admin-Rechten gestartete Powershell aus. In dieser setzen Sie dann folgendes Kommando ab:

Set-NspWebApiConfiguration -ShowCertificateSelectorUI

Es öffnet sich nun ein Fenster, in der Ihnen die verfügbaren Zertifikate angezeigt werden. Wählen Sie das gewünschte Zertifikat aus und bestätigen Sie die Auswahl. Starten Sie nun noch die Intranetrolle neu und Ihr Zertifikat ist auf der Disclaimer-Tool-Management-Webseite aktiv.