Kategorie: Server

Kategorien
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.

 

Kategorien
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.

Kategorien
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.

Kategorien
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.

Kategorien
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.

Kategorien
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.

Kategorien
Exchange

Exchange 2013 komplett von Hand aus der Domäne entfernen

Wenn man einen Exchange-Server komplett aus der Domäne entfernen möchte, sollte als erstes immer die Deinstallation über die Systemsteuerung versucht werden. Sollte dies fehlschlagen, so kann folgende Anleitung befolgt werden:

+++ NUR FÜR EINZELSERVERINSTALLATIONEN +++

  1. Öffnen Sie auf einem Domain Controller das Tool „ADSI Edit“
  2. Wählen Sie als erstes „Konfiguration“ um dann zu folgendem Pfad zu navigieren:
    CN=Configuration > CN=Services
    Löschen Sie folgende Ordner:
    CN=Microsoft Exchange & CN=Microsoft Exchange Autodiscover
  3. Erstellen Sie eine neue Verbindung und wählen dieses Mal „Default Naming Context“. Dort bitte folgende Ordner löschen:
    CN=Microsoft Exchange Security Groups & CN=Microsoft Exchange Security Objects
  4. Jetzt kann man das normale AD öffnen und in der OU „Users“ folgende User noch löschen:
    – DiscoverySearch Mailbox{GUID}
    – Exchange Online-ApplicationAccount
    – FederatedEmail.GUID
    – Migration.GUID
    – SystemMailbox{GUID}
    – HealthMailboxGUID

Wenn der Server anschließend neu aufgesetzt wird, so wäre hiermit die Deinstallation abgeschlossen. Soll auf das bestehende Betriebssystem weiterverwendet werden, so wäre folgendes noch zu tun:

  1. Über den Explorer folgenden Pfad löschen: C:\Programme\Microsoft\Exchange Server
  2. Im IIS sämtliche Exchange-Sites entfernen
  3. In der Registry folgende Keys entfernen:
    – ExchangeServer unter HK_L_M\Software\Microsoft
    – MSExchange[…] unter HK_L_M\CurrentControlSet\Services

Hiermit sollte alles endgültig abgeschlossen sein.

Kategorien
Terminal/RD Services

Terminal Services/Remote Desktop Services: Schlanker Windows 2012 (R2) Terminal Server ohne RD Connection Broker

Folgt man den Anweisungen aus dem TechNet von Microsoft, so muss man für einen 2012er Terminal Server ordentlich Features auf dem Server installieren. Um einen Lizenzierungsserver zu hinterlegen, muss eine komplette Infrastruktur mit oft gar nicht benötigtem Zeug installiert werden. Bestes Beispiel hierfür wäre der RD Connection Broker, der bei einem einfachen Terminal Server einfach keinen Sinn macht.

Sollten Sie also vor dem selben Problem stehen, können Sie folgende Anleitung befolgen:

  1. Installieren Sie nicht wie empfohlen die ganze „Remote Desktop Services Installation“ sondern wechseln Sie zur Rollen- und Featurebasierten Installation. Unter Rollen wählen Sie bitte nur „Remote Desktop Session Host„, mehr wird nicht benötigt.
  2. Nach dem Abschluss der Installation öffnen Sie bitte den Editor für die lokale Gruppenrichtlinie (gpedit.msc). Navigieren Sie dort zu folgendem Pfad:
    Local Computer Policy\Computer Configuration\ Administrative Vorlagen\Windows-Komponenten\Remotedesktopdienste\Remotedesktopsitzungs-Host\Lizenzierung
  3. Bearbeiten Sie bitte folgende Keys:

    Angegebene Remotedesktop-Lizenzserver verwenden:
    Status: Aktiviert
    Zu verwendende Lizenzserver: [FQDN des Lizenzservers]

    Remotedesktop-Lizenzierungsmodus festlegen:
    Status: Aktiviert
    Optionen: [Je nach Lizenztyp auf dem Lizenzserver]

Das sollte es gewesen sein. Wenn Sie jetzt die Lizenzierungsdiagnose öffnen, müsste alles grün sein. Ist dem nicht so, kann ich Ihnen noch folgenden Artikel ans Herz legen:

technet: Terminal Services/Remote Desktop Services: Credentials für Lizenzserver werden nicht gespeichert

Kategorien
Terminal/RD Services

Terminal Services/Remote Desktop Services: Credentials für Lizenzserver werden nicht gespeichert

Problem:
Schon seit dem Windows Server 2008 kann es zu Problemen kommen beim Hinterlegen der Credentials zum Zugriff auf den Lizenzserver. Oft wird die Benutzerkennung einfach nicht gespeichert und beim nächsten Öffnen der Lizenzierungsdiagnose besteht wieder keine Verbindung zum Lizenzserver.

Ursache:
Der Anmeldedatenspeicher (später Anmeldeinformationsverwaltung) speichert die Benutzerkennung unter Verwendung eines falschen Anmeldedaten-Typs. Richtig wäre „Windows Logon Credential“.

Lösung:
Gehen Sie auf dem betroffenen Terminal Server in die Systemsteuerung (klassische Ansicht) -> Anmeldeinformationsverwaltung. Löschen Sie (falls vorhanden) die für den Lizenzserver gesetzten „Generic“-Anmeldeinformationen und fügen Sie anschließend per Klick auf „Windows Anmeldeinformationen hinzufügen“ die Credentials erneut ein:

Internet- oder Netzwerkadresse: [FQDN des Lizenzservers]
Benutzername: DOMAIN\user
Kennwort: Sollte klar sein

Sobald Sie dies mit OK bestätigt haben, sollte die Lizensierungsdiagnose ohne Fehler aufgehen und alles korrekt anzeigen.

Kategorien
Exchange

Event ID 1677 – Unified Messaging kann nicht für einen Benutzer aktiviert werden

Wenn sich ein bestimmter User nicht für Unified Messaging aktivieren lässt und Sie folgende Fehlermeldung bekommen, dann haben wir hier die Lösung:

Error occurred during execution of UM Mailbox Cmdlet for user „/o=XXX/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=929fc9a62f634c198ea7f630a2593615-XXX“, Error: „Microsoft.Exchange.UM.UMCommon.UmUserException: Access to Active Directory failed.
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.CommitPasswordAndUpdateChecksum()
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.SetPassword(EncryptedBuffer digits, Boolean isExpired, LockOutResetMode lockoutResetMode)
at Microsoft.Exchange.UM.UMCommon.Utils.SetUserPassword(MailboxSession mbxSession, UMMailboxPolicy umMbxPolicy, ADUser adUser, String pin, Boolean expired, Boolean lockedOut)
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.<>c__DisplayClassa.<SaveUMPin>b__9()
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.ExecuteXSOOperation(Action function)“

Ursache: Diese typisch nichtssagende Meldung bekommen wir dann, wenn das Postfach aus irgendeinem Grund nicht in den (in der Address Book Policy festgelegten) Adresslisten eingetragen ist.

Behebung: Im ersten Schritt sollte man sich die Address Book Policy anschauen und feststellen, in welche Adresslisten das Postfach gehören sollte. Anschließend schauen wir uns das Postfach an und überprüfen, in welchen Listen es auch eingetragen ist. Im dritten Schritt überprüfen wir die Aufnahmeregeln der Listen, in denen das Postfach nicht ist aber sein sollte und führen dementsprechende Anpassungen durch.