Categories
Exchange Server Windows

Wie starte ich einen Exchange-Server in einem DAG-Cluster neu?

Anders als es der Begriff ‘Cluster’ vielleicht vermuten lässt, müssen einige Vorbereitungen getroffen werden, um einen Exchange-Server in einer “Database Availability Group” – kurz DAG – sauber neuzustarten. Macht man das nicht, so kann es gut gehen, im schlimmsten Falle fliegt einem allerdings der Datenbank-Index um die Ohren und die Suche funktioniert nicht mehr. Das wäre der schlimmste mir bekannte Fehler.

Um das zu vermeiden, machen wir folgendes:

Mittels dieses PowerShell-Befehls:

Get-MailboxDatabaseCopyStatus *

lassen wir uns alle Postfach-Datenbanken auf jedem eingehängten Server in der DAG ausgeben. Nun schauen wir nach Datenbanken, welche auf dem neuzustartenden Server den Status “Mounted” beziehungsweise “Eingehängt” haben. Sind solche Datenbanken vorhanden, muss folgender Befehl ausgeführt werden:

Move-ActiveMailboxDatabase -Server [Neuzustartender Server]

Hiermit erreichen wir, das die Datenbanken nicht mehr auf diesem Server eingehängt sind, sondern ein beliebiger anderer Server in der DAG diesen Job übernimmt.

Nun kann der Neustart durchgeführt werden. Sobald dieser durch ist, kann man mit dem ersten Befehl prüfen, ob alle Datenbanken den “Healthy”-Status haben bzw. nach kurzer Zeit wieder annehmen. Wichtig ist, dass alle Datenbanken einen solchen Status haben, bevor eine Verschiebung stattfindet. Ist dies der Fall, könnte auch mit dem nächsten Neustart fortgefahren werden.

Es wird davon abgeraten, innerhalb eines Clusters mehr als einen Server gleichzeitig neuzustarten.

 

Categories
CRM Server Windows

Dynamics CRM Reports-Error: Connector for Microsoft SQL Server Reporting Services is not installed

If you get the following Error whilst executing an Report:

Reporting Error

Reports cannot be run because the Connector for Microsoft SQL Server
Reporting Services, a required component for reporting, is not
installed on the server that is running Microsoft SQL Server Reporting
Services.

You may want to look at this post from Bhavesh Shastri.

Categories
Server SharePoint Windows

Deleting orphaned (non-existent) Users from SharePoint 2010

If you are removing/disabling Users from Active Directory, which had some permissions left on your SharePoint-Site, SharePoint will keep those Userprofiles in it’s Content-Database. This is a proposed behaviour, since this method ensures that SharePoint is still able to fill fields like “Modified by” or “Created by” with names from old users. However this also results in some negative points as the PeoplePicker will still show all old users because he’s using the same database as source.

To permanently delete those orphaned users, we have to follow the following steps:

First, we need to access the system group which contains all those records by using the following URL:

https://[SharePoint-URL]/_layouts/people.aspx?MembershipGroupId=0

Here you can mark all orphaned Users and delete them by clicking on Actions -> Remove Users from Site Collection.

That’s it!

Categories
Clients Office Windows

Reparieren Ihrer Persönlichen Ordner-Datei (.pst oder .ost) in Outlook

Merkmal


Outlook stürzt unerwartet ab und zeigt folgende Meldung:

AppName: Outlook.exe
AppVer: 14.0.4760.1000
ModName: Kernelbase.dll
ModVer: 6.1.7600.16385
Offset: 0003194b

Ursache


Diese Problem tritt bei dem Verfall der Outlook Dateien (.pst oder .ost) auf.

Lösung


Um dieses Problem zu lösen, nutzen Sie das “Tool zum Reparieren von Microsoft Office” um die Outlook Dateien zu reparieren.

1. Schließen Sie Outlook

2. Gehen Sie zu folgendem  Ordner:  C:\Programme\Microsoft Office\Office[Version]

3. Doppelklick Scanpst.exe

Unbenannt0

4. Klicken Sie im Dialogfenster “Tool zum Reparieren von Microsoft Office”  Durchsuchen.

Unbenannt

5. Wählen Sie Ihr Outlook Dateien (.pst oder .ost) aus, dann klicken sie Öffnen.

6. Klicken Sie im Dialogfenster “Tool zum Reparieren von Microsoft Office”  Start.

  • Bei Windows 7, Windows 10 und Windows Vista ist der Default Ort für die Outlook Dateien in Outlook 2010:

(.pst file)

C:\Users\username\Documents\Outlook-Dateien

Unbenannt1

(.ost file)

C:\Users\username\AppData\Local\Microsoft\Outlook

Unbenannt

Notiz: Um diesen Pfad für die .ost Datei zu sehen, müssen Sie die versteckten Dateien und Ordner sichtbar machen mit dn folgenden Schritten

1. Öffnen Sie die Ordneroptionen, indem Sie auf die Schaltfläche StartSchaltfläche  klicken, auf Systemsteuerung klicken, auf Darstellung und Anpassung klicken und dann auf Ordneroptionen klicken.

2. Klicken Sie auf die Registerkarte Ansicht.

3. Klicken Sie unter Erweiterte Einstellungen auf Ausgeblendete Dateien, Ordner und Laufwerke anzeigen, und klicken Sie anschließend auf OK.

7. Nachdem Ihre Datei gescannt wurde, überprüfen sie bitte die angezeigte Information des Dialogfensters “Tool zum Reparieren von Microsoft Office” .

Wichtig:  Setzen Sie den Hacken bei Sicherungskopie von geprüfter Datei vor Reparatur, damit das “Tool zum Reparieren von Microsoft Office” eine Backup Datei erstellt bevor es den Prozess der Reparatur startet.

Unbenannt2

8. Klicken Sie Reparieren.

9. Nachdem der Reparaturprozess abgeschlossen ist, klicken Sie OK.

Unbenannt3

Wenn der Reparaturprozess fertiggestellt ist, werden Sie folgende drei Dateien finden:

 File  Description
 filename.bak Das ist die ursprüngliche nicht reparierte Backup-Datei. Wenn sie auf diese Datei in Outlook zurückgreifen wollen, benennen Sie die .bak Datei um zu einer .pst Datei.
 filename.log  Dieses log file dokumentiert den Reparatur Prozess aufgeführt durch “Tool zum Reparieren von Microsoft Office”.
 filename.pst oder filename.ost  Dies ist die reparierte Outlook Datenbank Datei.

Unbenannt4

Categories
Exchange Server Windows

OneLiner: Get all Mail-Aliases of all Users / Groups in one OU

As we had this request currently, we’ve created the following OneLiners, which i’d like to share with you:

Get all Mailbox-Aliases:

Get-Mailbox -OrganizationalUnit "[DN of OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias

Get all DistributionGroup-Aliases:

get-distributiongroup -OrganizationalUnit "[DN of OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias
Categories
Exchange Server Windows

Exchange Public Folder – Subsequent Right Management (recursive)

Often you have to add rights for a new user long after the creation of a public folder. If there’s much Data in this folder and it’s subfolders, the usual method by using the Exchange Control Panel will often result in OutOfMemory-Exceptions. To prevent this behaviour, we could use the Exchange Scripts, which were placed on your server during the installation:

  1. At first we need a new Instance of the Exchange Management Shell (EMS) or a PowerShell Console with loaded Exchange Snapins (can be done by using the command “Add-PSSnapin Microsoft.Exchange.Management.Powershell.Snapin”).This needs to be done as the provided Scripts from Microsoft won’t import those Commands again.
  2. In the Shell we will now change our Working-Directory to the Path, were the Scripts are stored. This can be done by the following command:
    cd “C:\Program Files\Microsoft\Exchange Server\V15\Scripts”
    You may replace the Folder “V15” with the Versionnumber of your Exchange-Server.
  3. Now we will execute the following command:
    .\AddUsersToPFRecursive.ps1 -TopPublicFolder “\[folder-path]” -User “[UPN of the User]” -Permission “[Permission-Set]”
    Bsp.: .\AddUsersToPFRecursive.ps1 -TopPublicFolder “\technet” -User “randomguy@c4y.biz” -Permission “Owner”
  4. After a short delay the console will show you every folder as an output-line to confirm the modification of rights.

That’s it!

Categories
ADFS CRM Server SharePoint Windows

ADFS 3.0 – Extend Login-Token Lifetime

Without further Configuration, the Lifetime of a Login-Token in ADFS is very limited. To avoid permanent relogins, we need to extend the Lifetime by using PowerShell:

At first we need the Display Name of the Relying Party Trust. Therefore we’ll open the ADFS Management and navigate to ADFS -> Trust Relationships -> Relying Party Trusts.

Then we’ll execute the following one-liner by using the PowerShell-Console:

Get-ADFSRelyingPartyTrust -Name "[Display Name]" | Set-ADFSRelyingPartyTrust -TokenLifetime 720

The Parameter “-TokenLifetime” determines the Lifetime in Minutes. In our case we would have set the Lifetime to 12 Hours.

The changes made will apply immediately and all future Tokens will have now an extended Lifetime.

Categories
Exchange Server Windows

Mail-enabled Public Folder doesn’t receive external Mails

Since SP1 for Exchange 2013 it could be possible, that just mail-enabling a Public Folder isn’t enough to make this Folder receiving external Mails. This is caused by a missing permission for external Senders (which appear as “Anonymous”) to “create” items in this specific folder.

If you track an external message, you may receive the following error:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]};{FQDN=};{IP=}]}

To resolve this issue, you have to drop the following command within the Exchange Management Shell:

Add-PublicFolderClientPermission –identity “\Folder\Subfolder” –User Anonymous –AccessRights CreateItems

This should resolve your problem.

Categories
Exchange Server Windows

Script: Grant “SendAs”-Permission for all Groupmembers in a Distribution Group

 

This Script will go through all Distribution Groups and grants SendAs-Permissions for all Groupmembers by using the Group itself instead of each User:

Grant-SendAs-To-Group

Categories
Hyper-V Server VMM Windows

Frequent VMM-Migrationerrors and possible solutions

Migrationen über den VMM (vorallem zwischen Clustern) können oft zu merkwürdigen Fehlern führen, die sich nicht immer logisch erklären lassen. Aus diesem Grund habe ich hier mal die mir widerfahrenen Probleme aufgelistet, gemeinsam mit Lösungsansätzen.

  • Es konnte keine verfügbare Verbindung mit dem ausgewählten VM-Netzwerk gefunden werden.
  • Es wurde keine Verbindung zu “[VM-Netzwerkname]” mit ausreichenden Ressourcen gefunden.

Das ist ein seltsamer Bug. Wenn wir jedoch im VMM aus dem Menüband die PowerShell-Konsole öffnen, und darüber die Migration durchführen, so funktioniert es ohne Probleme – Vorausgesetzt natürlich, dass das Netzwerk tatsächlich an dem Zielhost anliegt. Hierzu gehen wir folgendermaßen vor:

$VMHost = Get-VMHost -ComputerName "[Ziel-Host]"
$VM = Get-VM -Name "[Zu migrierdende VM]"
$VMPath = $VMhost.Vmpaths[[Index des korrekten Speicherorts]]
Move-VM -VM $VM -VMHost $VMHost -Path $VMPath

Move-VM : Die VM “XXXXX” kann aufgrund von Inkompatibilitätsproblemen nicht zu Host “XXXXXXX” migriert
werden. The virtual machine ‘XXXXX’ is using processor-specific features not supported on physical computer ‘XXXX’.
To allow for migration of this virtual machine to physical computers with different processors, modify the virtual
machine settings to limit the processor features used by the virtual machine. (Virtual machine ID
xxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx) (Fehler-ID: 23008, Detaillierter Fehler: )

Beheben Sie das Inkompatibilitätsproblem, und wiederholen Sie den Migrationsvorgang.

Hier ist die VM auf einem Host erstellt worden, dessen Prozessorgeneration neuer ist, als der Zielhost der Migration. Behoben werden kann das Ganze, in dem man die VM herunterfährt, den Haken unter “Hardware” -> “Prozessor” -> “Migration zu einem virtuellen Maschinenhost mit abweichender Prozessorversion zulassen” setzt und dann die Migration erneut durchführt. Nach der Migration sollte die Maschine erneut heruntergefahren werden, um diesen Haken wieder zu entfernen.


Move-VM : Der Hostvorgang auf dem Server “XXXXXXXXX” kann von VMM aufgrund des folgenden Fehlers nicht
abgeschlossen werden: Virtual machine migration operation for ‘XXXXXXXX’ failed at migration source ‘XXXXXXX’. (Virtual
machine ID xxxxxxxx-xxxxxx-xxxxxx-xxxxxxxxx)
Virtual machine migration for ‘XXXXXXX’ failed because configuration data root cannot be changed for a clustered
virtual machine. (Virtual machine ID xxxxx-xxxxxxxxx-xxxxxxxx-xxxxxx) (Fehler-ID: 12700, Detaillierter Fehler:
Unknown error (0x8005))

Beheben Sie das Problem auf dem Host, und wiederholen Sie dann den Vorgang.

Dieser Fehler kann behoben werden, indem man im Anschluss an den Fehler auf “Reparieren” -> “Ignorieren” klickt, und anschließend die Migration erneut triggert. Notfalls über PowerShell.