Category: Windows

Categories
Certificates Exchange Server Windows

Exchange 2007-2013: Umstellen der internen URLs auf die externen Namen

Um den vollen Funktionsumfang aller Exchange-Dienste ausnutzen zu können, müssen alle Namen, sowohl intern als auch extern, mit einem oder mehreren Zertifikaten abgedeckt werden. Nun hat man zwei Möglichkeiten, das ganze zu bewerkstelligen:

  1. Verwendung von zwei unterschiedlichen Zertifikaten: Eins ausgestellt von der internen CA zur Abdeckung aller internen URLs und eins ausgestellt von einem Zertifikatsanbieter Ihrer Wahl zur Abdeckung der externen URLs.
  2. Umstellung der internen URLs auf die externen, um anschließend im internen DNS die öffentlichen URLs zusätzlich zu pflegen, allerdings unter Verwendung von internen IPs. Hier wird dann nur ein Zertifikat benötigt.

Die bisherige dritte Möglichkeit, nämlich sowohl lokale als auch öffentliche URLs in ein Zertifikat zu packen, wird ab dem 1. November 2015 nicht mehr unterstützt. Für mehr Informationen hierzu klicken Sie bitte auf folgenden Link: https://www.icann.org/en/system/files/files/sac-057-en.pdf

Die zweite Möglichkeit werden wir nun durchführen. Hierfür müssen wir allerdings einige Befehle in der Exchange Management Shell absetzen. Diese lauten wie folgt:

Set-ClientAccessServer -Identity <HostName> -AutodiscoverServiceInternalUri https://mail.example.de/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity "<HostName>\EWS (Default Web Site)" -InternalUrl https://mail.example.de/ews/exchange.asmx

Set-OABVirtualDirectory -Identity "<HostName>\oab (Default Web Site)" -InternalUrl https://mail.example.de/oab

Set-ActiveSyncVirtualDirectory -Identity "<HostName>\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.example.de/Microsoft-Server-ActiveSync

Set-OWAVirtualDirectory -Identity "<HostName>\owa (Default Web Site)" -InternalUrl https://mail.example.de/owa

Set-ECPVirtualDirectory -Identity "<HostName>\ecp (Default Web Site)" -InternalUrl https://mail.example.de/ecp

Optional (kann zuvor über Get-OutlookAnywhere getestet werden):

Set-OutlookAnywhere -Identity "<HostName>\Rpc (Default Web Site)" -InternalHostname  -InternalClientsRequireSsl $true

Im Anschluss daran muss man den IIS Application Pool recyclen, damit die Änderungen wirksam werden. Hierfür muss der IIS Manager geöffnet werden. Darin angekommen, klicken wir unter Application Pools auf den MSExchangeAutodiscoverAppPool und anschließend auf Recycle. Sobald dies erledigt ist, sind die Einstellungen übernommen und die Clients ziehen sich bei der nächsten Autodiscover-Abfrage die neuen URLs.

Categories
Hyper-V Server Windows

Hyper-V: Shared Nothing Live Migration zwischen Clustern

Shared Nothing Live Migration ist nun bereits seit der Servergeneration 2012 fest integriert und wurde nun auch bei uns im Rahmen von diversen Clusteraktualisierungen zu einem echten Thema. Wie das Ganze funktioniert, werden wir hier im Detail nicht mehr erläutern. Nur soviel sei dazu gesagt: Während die ursprüngliche Live-Migration einen gemeinsam genutzten Storagepool voraussetzt, wird bei der Shared Nothing Live Migration (kurz: VSM) der tatsächliche Speicherort der VM so lange für den Zielhost freigegeben, bis dieser alle benötigten Dateien in den für ihn vorgesehenen Storagepool verschoben hat. Anschließend wird die Freigabe geschlossen, die VM läuft mit max. 2 verlorenen Pings weiter und die Migration ist erfolgreich beendet.

Wie Sie sich vielleicht vorstellen können, bedeutet dieser veränderte Zugriff der Hosts aufeinander logischerweise mehr Konfigurationsaufwand. Vorallem dann, wenn man nicht wie von Microsoft vorgesehen jeden Cluster in die selbe Domain schiebt, sondern für jeden Cluster eine eigene Domain hat. Wir werden Ihnen hier schrittweise aufzeigen, wie wir vorgegangen sind, um dennoch die VSM-Migration zu ermöglichen. Dabei wird auch Bezug auf die Migration über den System Center Virtual Machine Manager genommen, da wir diesen zur Verwaltung unserer Cluster verwenden.

 

Schritt 1 – Trusts soweit das Auge reicht
Als erstes sorgten wir dafür, dass sich sämtliche Clusterdomains in einer Vertrauensstellung zueinander befanden. Hierzu wurde immer ein Two-Way-Forest-Trust verwendet. Mehr gibt es an dieser Stelle eigentlich nicht zu sagen.

 

Schritt 2 – Pro Domain eine Gruppenrichtlinie
Nun machen wir pro Clusterdomäne eine Gruppenrichtlinie, die dafür sorgt, dass die Administratoren und Hosts aus den anderen Clusterdomänen Vollzugriff auf die Hosts der Clusterdomain haben:

Beispiel-GPO
Beispiel-GPO

 

Schritt 3 – Portfreigabe
Damit die Migration durchgeführt werden kann, müssen diverse Portfreigaben gesetzt werden. Zusätzlich zu den gewöhnlichen LDAP-Ports usw. gesellt sich hier der Port TCP 6600. Ohne den geht gar nichts. Hier wäre es am Besten, einfach das Firewall-Monitoring zu öffnen um zu schauen, was noch zwischen den Clustern geblockt wird.

 

Schritt 4 – Kerberos
Nun wird es spannend, denn hier müssen wir von jeder Empfehlung abweichen auf Grund unserer Multi-Domain-Struktur. Wir klicken also im ersten Cluster im Domain Controller auf “Active Directory User and Computers” und suchen die Maschinen-Accounts unserer Hosts. Wir picken uns den ersten Host heraus, öffnen dessen Properties und klicken auf den Tab “Delegation”. Hier müssten wir eigentlich alle Hosts einzeln für die benötigten Services auf dem Host berechtigen. Unser einziges Problem: Wir können hier keine Hosts aus Vertrauensstellungen auswählen. Stattdessen setzen wir also unseren Haken bei “Trust this Computer for Delegation to any service (Kerberos only)”. Da dies ein Stück weit auch die Tore öffnet, ist es umso wichtiger, die Firewall in Schritt 3 sorgfältig zu konfigurieren. Diese Aktion ist für jeden Host in jedem Cluster zu wiederholen.

 

Schritt 5 – Hyper-V Einstellungen setzen
Nun muss man noch auf jedem einzelnen Hyper-V-Host die generellen Einstellungen anpassen. Dazu öffnen wir den Hyper-V Manager, klicken auf Hyper-V Settings und wählen dann links die Option “Live Migrations”. Folgende Einstellungen müssen gesetzt werden:

[x] Enable incoming and outgoing live migrations
[x] Use any available network for live migration (kann auch geändert werden)

-> Links die Option Live Migrations über das + erweitern und auch noch folgende Einstellungen setzen:

[x] Use Kerberos
[x] TCP/IP oder Compression (das eine belastet das Netzwerk länger, das andere dafür die CPU mehr)

 

Schritt 6 – Netzwerke publizieren (Nur beim VMM)
Idealerweise haben Sie die Netze schon immer über den VMM gepflegt, ansonsten wird es hier nochmal sehr trocken. Sobald Sie alle Cluster im VMM integriert haben, sollten Sie die Netzwerke anlegen. Ich kann hier nur jedem ans Herz legen, es vernünftig zu machen, sprich ein Netz pro VLAN. Dies hängt ganz einfach mit den Erweiterungsmöglichkeiten des VMM zusammen, wie z.B. dem App Controller, bei welchem Sie den Usern Clouds zuordnen können (Ja, geht auch ohne, aber hier machts auch Sinn). Den Clouds können Sie verfügbare Netze zuweisen, nicht jedoch nur einzelne VLANs aus einem Netz. Nachdem Sie jedes Netz angelegt und die Haken gesetzt haben, für welche Hosts diese Netze verfügbar sein sollen, müssen Sie nun nochmal bei jedem Host im VMM in die Eigenschaften reingehen. Unter dem Punkt Hardware weisen Sie nun den entsprechenden Netzwerkkarten die verfügbaren VLANs zu. Dies ist leider unumgänglich um VMs mit Netzwerkkarten von A nach B umziehen zu können. Man kann es sich leichter machen mit sogenannten Port-Profiles, danach am Besten einfach mal googlen.

 

Nach diesen Schritten sollte der Live-Migration nichts mehr im Wege stehen. Viel Spaß!

Categories
CRM

rsProcessingAborted – CRM 2011-X Custom Fetch Reports

Betroffene Systeme:
Microsoft Dynamics CRM Server 2011, 2013, 2015

Genaue Beschreibung:
Bei der Ausführung eines selbsterstellten FetchXML-Reports wird einem anstatt des Reports nur folgender Fehler angezeigt:

The report cannot be displayed. (rsProcessing Aborted)

Geht man nun auf den Reporting-Server und schaut in die Logs (Standardpfad: C:\Program Files\Microsoft SQL Server\<Datenbank>\Reporting Services\LogFiles), so wird man unter anderem folgende Meldungen finden:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception.
System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception.
System.ComponentModel.Win32Exception: The target principal name is incorrect

Ursache:
Die FetchXML-Abfrage muss einen hierfür zuständigen HTTP SPN abfragen können, um korrekt mit dem Reporting-Server kommunizieren zu können. Läuft der CRM Application Pool unter einem Domain-Account, so wird diese Abfrage fehlschlagen, da der SPN nicht von Haus aus gesetzt wird.

Behebung:
Um diesen Fehler zu beheben, sind folgende Schritte notwendig:

  • Im IIS gehen wir auf die CRM-Seite, klicken auf Authentication, highlighten “Windows Authentication” und aktivieren dann unter Advanced Settings den Haken für “Enable Kernel-mode authentication”.
  • Anschließend setzen wir folgende Befehle in der Kommandozeile ab:
    PS> setspn -a “HTTP/<CRM-Srv – Hostname>” “<Application Service User>”
    PS> setspn -a “HTTP/<CRM-Srv – FQDN>” “<Application Service User>”

Damit sollten die FetchXML-Reports wieder laufen.

Categories
Exchange

SMTP Tarpitting – Sinn und Unsinn

Was ist das?

SMTP Tarpitting ist ein pro Empfangskonnektor setzbarer Parameter. Dieser sorgt dafür, dass beim Versand über den jeweiligen Konnektor an eine dem Exchange nicht unmittelbar bekannte Adresse (sprich extern oder nicht vergebene Aliase) eine definierte Verzögerung eintritt.

Macht das Sinn?

Ja und nein. Es macht Sinn für meistens genau einen Konnektor, nämlich den, der Mails von extern empfängt. Wenn man nun versucht, den Exchange-Server mit Spam zu überschütten, wird die ein oder andere falsche Adresse dabei sein, was immer zu einer Verzögerung führt. Vielen Spammern wird das dann letztendlich zu blöd, da sie diese Zeit sinnvoller nützen können.
Keinen Sinn macht es jedoch für interne Relays, die meist zügig die Mails nach außen schieben sollen. Hier wird so manche externe Adresse dabei sein, die diese Verzögerung bewirkt. Viele einfach programmierte SMTP-Konnektoren werden bis die Response kommt sogar komplett freezen. Daher macht dies intern wirklich keinerlei Sinn.

Konfigurieren der Konnektoren

Standardmäßig sind 5sek. pro Konnektor gesetzt. Um beim erstgenannten Empfangskonnektor für Mails aus dem www die Zeit sogar noch zu erhöhen, kann folgender Befehl ausgeführt werden: 

Set-ReceiveConnector “FromInternet” -tarpitinterval 00:00:10

Um z.B. für interne Relays die Tarpitting komlett abzuschalten, ist stattdessen dieser Befehl hier nötig: 
Set-ReceiveConnector “Internal” -tarpitinterval 00:00:00

Categories
SharePoint

Event 5239 – SharePoint Excel Error

Wenn Sie folgenden Fehler:
excel-sp

 

… kombiniert mit diesem Event auf dem SharePoint-Server bekommen: 

There was an error in communicating with Excel Calculation Services http://SP-SERVER:12345/abcdef-asd2321324142434-abc232/ExcelService*.asmx exception: The remote server returned an error: (403) Forbidden.
[Session: 
User: DOMAIN\user].
.
… dann sind vermutlich die Performance Counter kaputt.

Dies lässt sich wie folgt reparieren:

  1. Öffnen Sie auf dem Server ein CMD/PowerShell-Fenster als Admin
  2. Geben Sie “lodctr /r” ein, um die Counter zu rebuilden
  3. Geben Sie “iisreset /noforce” ein um die IIS-Dienste einmal im Kreis zu schicken.

 

Categories
ADFS CRM

Event 3005, ID4175 – CRM & ADFS-Error

Fehler: 

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 26.01.2015 09:16:59 
Event time (UTC): 26.01.2015 08:16:59 
Event ID: 7c097f8cb25c47eaaee0b06824c52971 
Event sequence: 861 
Event occurrence: 109 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT-1-130666738292352050 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\ 
    Machine name: XXXXXXXX
 
Process information: 
    Process ID: 6392 
    Process name: w3wp.exe 
    Account name: XXXX\XXXXXXXXXX 
 
Exception information: 
    Exception type: SecurityTokenException 
    Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

 
 
Request information: 
    Request URL: https://XXXXXXXXX.XXXXXXXXX.XXXX:443/default.aspx 
    Request path: /default.aspx 
    User host address: XXX.XXX.XXX.XXX
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: XXXX\XXXXXXXXXX 
 
Thread information: 
    Thread ID: 24 
    Thread account name: XXXX\XXXXXXXXXX 
    Is impersonating: True 
    Stack trace:    at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 
 
Custom event details:

Ursache:
Wenn das selbsterstellte Zertifikat zur Kommunikation zwischen CRM und ADFS kurz vorm auslaufen ist (~1 Woche), stellt das ADFS ein neues Zertifikat aus und verwendet dieses auch sofort. Die eigentlichen CRM-Server bekommen davon allerdings wenig mit, haben immer noch den Thumbprint vom alten Zertifikat gespeichert und können mit dem nun verwendeten neuen gar nichts anfangen. Dies versucht uns diese Fehlermeldung zu übermitteln.

Behebung:
Zuerst führen wir auf dem ADFS-Server folgende Powershell-Befehle aus: 

Set-AdfsProperties -AutoCertificateRollover $true
Update-AdfsCertificate -Urgent
Im Anschluss daran öffnen wir den CRM Deployment Manager auf dem CRM-Server und führen diese beiden Assistenten nochmals aus:

  • Configure Claims-Based Authentication Unbedingt richtiges (neues) Zertifikat auswählen.
  • Configure Internet-Facing Deployment

Diese müssen einfach nur durchgeklickt werden, sprich “Next”, “Next”, […], Apply.
Zurück auf dem ADFS-Server muss nun der ADFS-Dienst neugestartet werden (“Active Directory Federation Services”).
Jetzt gehts wieder zum CRM-Server, wo der “Microsoft Dynamics CRM Asynchronous Processing Service” neugestartet werden muss. Als letzter Schritt muss noch ein iisreset ausgeführt werden. Nun sollte alles wieder gehen.

Categories
Exchange

PST-Export auf dem Exchange-Server (ab 2010)

Um ein PST-File von einem Postfach direkt auf dem Exchange-Server zu exportieren, muss folgendes getan werden:

Als erstes müssen wir uns an einem ClientAccess-Server anmelden. Der User mit dem wir uns dort anmelden, benötigt dann noch Rechte für den Export. Das ganze funktioniert über eine Rollenzuweisung. Dies ist absolut notwendig, auch als Administrator hat man diese Rolle normalerweise nicht. Jedoch ist der Schritt nur einmal pro User notwendig, da die Rollenzuweisungen permanent sind.

Hier die Rollenzuweisung:  

New-ManagementRoleAssignment –Role "Mailbox Import Export" –User domainuser

Anschließend muss man die Exchange-Shell nochmal schließen und neu öffnen. Dieser Schritt ist nötig, da die Shell beim Start die erlaubten Befehle bekommt. Starten wir Sie nicht neu, so weiß sie nicht, dass nun neue Befehle möglich sind.

Nach dem Neustart kann der Befehl mit den notwendigen Anpassungen abgesetzt werden: 

New-MailboxExportRequest -Mailbox user@domain.tld –FilePath "localhostc$pstusername.pst"

Damit ist der Request abgesetzt. Wann dieser bearbeitet wird, entscheidet ganz alleine der Exchange-Server durch Abwägung verschiedener Einflüsse wie Auslastung usw.

Der aktuelle Status lässt sich abrufen, in dem folgender Befehl abgesendet wird:

Get-MailboxExportRequest

Sobald der Request dann igendwann abgeschlossen ist, kann man ihn wieder löschen über folgenden Befehl:

Get-MailboxExportRequest | Remove-MailboxExportRequest

Hierbei muss nur beachtet werden, dass mit diesem Befehl alle Requests beendet werden. Also nur abfeuern, wenn auch alle Requests durch sind. Das wars auch schon.

Categories
Exchange

Verwaiste und alte Exchange 2000/2003-Einträge manuell aus dem Active Directory entfernen

Letzte Woche wurde bei einem Kunden von uns lokal ein neuer Exchange-Server parallel zu einer 2007er Installation hochgezogen, um anschließend die Postfächer zu migrieren.

Beim Check, welcher vor der Installation durchgeführt wird, bemängelte das Setup noch vorhandene Exchange 2000/2003-Einträge im AD. Diese(n) Server gibt es allerdings schon seit geraumer Zeit nicht mehr. Somit mussten wir die Einträge manuell entfernen – Zeit für den ADSI-Editor.

Wir verbinden uns also per ADSI Edit auf die betroffene Domain. Als “bekannten Namenskontext” wählen wir Konfiguration aus. Dann bitte folgenden Pfad befolgen:

  • Konfiguration [Domain.local]
    • CN=Configuration,DC=Domain,DC=local
      • CN=Services
        • CN=Microsoft Exchange
          • CN=[Organisationsname]
            • CN=Administrative Groups
              • CN=Erste administrative Gruppe
                • CN=Servers

Unter diesem Container finden wir nun alle verwaisten Servereinträge. Aus diesem Grund kann man alle Container innerhalb des CN=Servers entfernen. Auf keinen Fall aber irgendetwas anderes. Durch das Löschen dieser Server sollte die Meldung weggehen.

Categories
Hyper-V

vSwitch auf Hyper-V Server 2012 und Core Server Installationen erstellen

Als erstes erstellen wir den Switch, welcher einem Netzwerkinterface zugewiesen werden muss. Man kann hier auch ein Teaming verwenden, wie in diesem Beitrag beschrieben.  Wichtig ist der Name des Interfaces, der nun verwendet wird: 

#vSwitch-Name
$VSName = "abc"

#Interface auf das der vSwitch gelegt wird
$ethernet = Get-NetAdapter "Name des Interfaces"

New-VMSwitch -Name $VSName -NetAdapterName $ethernet.Name -AllowManagementOS $true
.

Dieser vSwitch hat nun weder IP noch VLAN zugewiesen. Um dies zu erledigen, müssen noch folgende Befehle ausgeführt werden: 
#VLAN
$vlan = "1337"

#IP-Adresse
$ip = "xxx.xxx.xxx.xxx"

#Anzahl Netbits (SNM)
$PreLe = "24"

#Gateway
$GW = "xxx.xxx.xxx.xxx"

#Interface-Alias (angeglichen an MS-Schreibweise bei Ausführung über Assistent)
$IfAlias = "vEthernet ($VSName)"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName $VSName -Access -VlanId $vlan
New-NetIPAddress -InterfaceAlias $IfAlias -IPAddress $ip -PrefixLength $PreLe -DefaultGateway $gw
.

Fertig ist der vSwitch.

Categories
Hyper-V Scripts

NIC-Teaming auf Hyper-V Server 2012 (R2) und Core Servern via PowerShell

Wenn an sich mehr Netzwerkbuchsen im Server verbaut sind als für das Teaming benötigt, so müssen als erstes die richtigen Anschlüsse fürs Teaming deklariert werden. Dies ist notwendig da die Benennung in Windows absolut gar nichts mit der physikalischen Anordnung am Server selbst zu tun hat.
Ich habe es mir da sehr einfach gemacht: Alle Netzwerkkabel abgesteckt und dann ein Kabel (möglichst mit DHCP-Server dahinter) nacheinander in jede Teaming-Buchse eingesteckt, immer gefolgt von folgendem PowerShell-Befehl:

Get-NetAdapter -Physical | where {$_.Status -eq "Up"} | Get-NetIPConfiguration
.

Dabei sollte man sich immer die Property “Interface Alias” notieren.

Mit Hilfe dieser Aliase geht es nun zum zweiten PowerShell-Befehl:

$name = "NIC TEAM"
$team = New-NetLbfoTeam -Name $name -TeamNicName ($name) -TeamMembers "InterfaceAlias1","InterfaceAlias2","[...]" -TeamingMode Lacp -LoadBalancingAlgorithm HyperVPort -Confirm $false
.

Hier wird die Option “-TeamMembers” mit den zuvor notierten Aliasen in der angezeigten Schreibweise aufgefüllt.