First of all an Input file is needed to read the userlist. Targetaddress.csv is the file name used in the script below. The following two entries are the only attributes which are used.

LegacyExchangeDN,mail.. From the mail attribut value everything is stripped of after the @ and replaced with ex2010.de then this string is put into targetaddress with the SMTP:name@ex2010.de.

A log file is also created in the directory where the script is called. The filename of the log file is logging_set_targetaddress.txt

First the script reads the Input file targetaddress.csv. Then it tries to find the user with the E-Mail address of the value "mail".

In case the result is not equal 1 the script will do nothing and will write an error in the log file.

--------------------------------------------------------------------------------------------------------

Please note that this script is just an example script and needs to be adapted

------------------- ------------------------------------------------------------------------------------

 ------------------- Start of script ----------------------------------------------------------------------

Option Explicit
Const ForWriting = 2, ForAppending = 8, ForReading = 1
Const CreateIfNotExist = True
Const DoNotCreate = False

Dim FSO, file, Benutzer
Dim TextZeile, data
Dim rootDSE
Dim conn, Email, LDAPStr, Mystring, vpathfichout, strDomain, objCommand
Dim oPerson, domainname, objRoot, username, cn, cmd, rs, strXSMTPContainer, strX500Container, strAddrPrefix, strSMTPPrefix, pre, dummy,dummy1

vpathfichout = "logging_set_targetaddress.txt"

WritetoFile vpathfichout, " Skript gestartet am: " & Date() & " " & Time()

Set FSO=CreateObject("Scripting.FileSystemObject")
Set file = FSO.OpenTextFile("targetaddress.csv", ForReading, False)

strSMTPPrefix ="SMTP:"

if domainname = "" then
 set objRoot = getobject("LDAP://RootDSE")
 domainname = objRoot.get("defaultNamingContext")
end if

TextZeile=file.Readline()  ' Einlesen der Headerzeile

while not file.AtEndOfStream
  TextZeile=file.Readline()
  If IsNull(TextZeile) Then
   WScript.Quit
  End If
     Benutzer=Split(TextZeile,",")
     'wscript.echo Benutzer(0) & ";" & Benutzer(1)
     username = Benutzer(1)
     If username <> "" then
   wscript.echo finduser (username,domainname)
 End if
wend
file.Close
WritetoFile vpathfichout, " Skript beendet am: " & Date() & " " & Time()

Function FindUser(Byval UserName, Byval Domain) 

 set cn = createobject("ADODB.Connection")
 set cmd = createobject("ADODB.Command")
 set rs = createobject("ADODB.Recordset")

 cn.open "Provider=ADsDSOObject;"
 
 cmd.activeconnection=cn
 cmd.commandtext="SELECT ADsPath FROM 'LDAP://" & Domain & _
    "' WHERE mail = '" & UserName & "'"
 
 set rs = cmd.execute

 if err<>0 then
  FindUser="Error connecting to Active Directory Database:" & err.Description
  WritetoFile vpathfichout, "Error connecting to Active Directory Database:" & err.Description
 else
  if not rs.BOF and not rs.EOF then
   Set oPerson = GetObject(rs.Fields(0).Value)
   strXSMTPContainer= Benutzer(1)
   dummy1= Split(strXSMTPContainer,"@",-1,1)

   dummy = dummy1(0) & "@ex2010.de"
   wscript.echo "Routingadresse: " & dummy

   oPerson.PutEx 3, "targetAddress", Array(strSMTPPrefix & dummy)
         oPerson.SetInfo
   wscript.echo err.number & err.description

   'wscript.echo "Hinzufügen von targetaddress : " & strSMTPPrefix  & strXSMTPContainer
   WritetoFile vpathfichout, "Hinzufügen von " & strSMTPPrefix  & " " & strXSMTPContainer
   strXSMTPContainer =""
       rs.MoveFirst
       FindUser = rs(0)
  else
   FindUser = Benutzer(1) & " Nicht gefunden"
   WritetoFile vpathfichout, Benutzer(1) & " Nicht gefunden"
  end if
 end if
 cn.close
end Function

Sub WritetoFile (FilePathName, Data)
Dim Log
Dim fs
 Set fs = CreateObject("Scripting.FileSystemObject")
 Set Log = fs.OpenTextFile(FilePathName, ForAppending, CreateIfNotExist)
 Log.Writeline data
 Log.Close
end Sub

 ------------------- End of script ----------------------------------------------------------------------

Save the script example as yourfilename.vbs

Start the script with the following command: cscript yourfilename.vbs

But if you want to have data over a longer period of time you have to write the Output data from the Cmd-Let e.g. to a SQL database.

First have a look what the cmd-let will do. 

The following definition is located on SQL Server

Databasename: MailOperation

Servername: WIN81\SQLExpress

The following columns are definied under tbl.MailboxStatistics:

The Output of the Cmd-let get-Mailboxstatistics must be converted to the right format for the SQL database MailOperation as shown above.

$MailboxServerStatistics = Get-MailboxStatistics -server $MailboxServer.identity

Once this is all done via the preferred method I want to show in this post how to connect and write to SQL Server instance from powershell.

First establish a Connection to the database:

 $SQLConnection = New-Object System.Data.SqlClient.SqlConnection
 $SQLConnection.ConnectionString = "Data Source=$SQLServer;Integrated Security=true;Initial Catalog=$SQLDatabase;"
 $SQLConnection.Open()
 if($?) {
  Write-Host ("SQL Connection established.")

  Write-Log ("SQL Connection established.")
  Write-Log ("")
 } else {
  Write-Host ("!!! No SQL Connection established. ") -foregroundcolor "yellow" -backgroundcolor "black"
 }

 # Create Command object for sub sequent commands
 $SQLCommand = $SQLConnection.CreateCommand()

    $SQLCommandText = "INSERT INTO tblMailboxStatistic (
              AssociatedItemCount,
              DatabaseName,
              DeletedItemCount,
              DisconnectDate,
              DisconnectReason,
              DisplayName,
              ItemCount,
              LastLoggedOnUserAccount,
              LastLogoffTime,
              LegacyDN,
              MailboxGuid,
              ObjectClass,
              StorageLimitStatus,
              TotalDeletedItemSize,
              TotalItemSize,
              MailboxTableIdentifier,
              ServerName,
              StorageGroupName,
              MoveHistory,
              IsQuarantined,
              IsArchiveMailbox,
              IsValid,
              MapiIdentity,
              OriginatingServer,
              UsrObjectGuid,
              UsrObjectSid) `n "
      $SQLCommandText += "VALUES (`n    "
      $SQLCommandText += $MailboxInfoSql.AssociatedItemCount + ", `n    "
      $SQLCommandText += $MailboxInfoSql.DatabaseName + ", `n    "
      $SQLCommandText += $MailboxInfoSql.DeletedItemCount + ", `n    "
      $SQLCommandText += $MailboxInfoSql.DisconnectDate + ", `n    "
      $SQLCommandText += $MailboxInfoSql.DisconnectReason + ", `n    "
      $SQLCommandText += $MailboxInfoSql.DisplayName + ", `n    "
      $SQLCommandText += $MailboxInfoSql.ItemCount + ", `n    "
      $SQLCommandText += $MailboxInfoSql.LastLoggedOnUserAccount + ", `n    "
      $SQLCommandText += $MailboxInfoSql.LastLogoffTime + ", `n    "
      $SQLCommandText += $MailboxInfoSql.LegacyDN + ", `n    "
      $SQLCommandText += $MailboxInfoSql.MailboxGuid + ", `n    "
      $SQLCommandText += $MailboxInfoSql.ObjectClass + ", `n    "
      $SQLCommandText += $MailboxInfoSql.StorageLimitStatus + ", `n    "
      $SQLCommandText += $MailboxInfoSql.TotalDeletedItemSize + ", `n    "
      $SQLCommandText += $MailboxInfoSql.TotalItemSize + ", `n    "
      $SQLCommandText += $MailboxInfoSql.MailboxTableIdentifier + ", `n    "
      $SQLCommandText += $MailboxInfoSql.ServerName + ", `n    "
      $SQLCommandText += $MailboxInfoSql.StorageGroupName + ", `n    "
      $SQLCommandText += $MailboxInfoSql.MoveHistory + ", `n    "
      $SQLCommandText += $MailboxInfoSql.IsQuarantined + ", `n    "
      $SQLCommandText += $MailboxInfoSql.IsArchiveMailbox + ", `n    "
      $SQLCommandText += $MailboxInfoSql.IsValid + ", `n    "
      $SQLCommandText += $MailboxInfoSql.MapiIdentity + ", `n    "
      $SQLCommandText += $MailboxInfoSql.OriginatingServer + ", `n    "
      $SQLCommandText += $MailboxInfoSql.UsrObjectGuid + ", `n    "
      $SQLCommandText += $MailboxInfoSql.UsrObjectSid + "`n    "
      $SQLCommandText += ")"
   Write-Debug ("  SQL Command: " + $SQLCommandText)
            $SQLCommand.CommandText = $SQLCommandText
            $SQLCommand.ExecuteNonQuery()   

if (!$SQLConnection -eq $null) {
 $SQLConnection.Close()
}

This blog will show how this new feature can be used. Imagine your organization has the requirement to not show all Exchange
users the whole global address list. For example you have two different departments which should only see Exchange users from their own department.

The first step is two create two different new global address lists. In this example these are called department1 and department2.

Creating two new global address lists

To separate the two departments it is necessary to create to global address lists for them.
This can be done via the Exchange Management shell:

New-GlobalAddresslist "Department1" -ConditionalDepartment "Department1" -IncludedRecipients "AllRecipients"

New-GlobalAddresslist "Department2"  -ConditionalDepartment "Department2" -IncludedRecipients "AllRecipients"

Creating two different address lists for the two departments

Create two new address lists via the Exchange Management console for department1 and department2:

Enter the name and display name in the first dialog box.

Choose the recipient container for the new address list and select “Users with Exchange mailboxes”. In this example the whole domain is selected.

Mark “Recipient is in a department” and under Step2 enter the value for the attribute department.

Choose under Schedule “Immediately”.

Under configuration summary verify the settings and create the address list by clicking on the “New” button.

The address list is created.

Now create an address list for the department1 in the organization in the same way as for department2. In the Exchange Management console under Address
Lists there are now four new address lists. Two GALs and two addresslists.

Creating two offline address books for the two different departments

Two different offline address books for these two departments are needed. These offline address books are created via the Exchange Management console:

Creating two address book policies for the two departments

After the creation of two new address lists, global address lists and offline address books the creation of two different address book policies for the two departments department1 and department2 will be done via the Exchange Management console:

In case there is a requirements for different room lists for the two departments this can also be achieved in the same way.

Assigning the address book policy to an Exchange user

Joe Contoso is a member of department1 so his mailbox will be assigned to the “Department1” address book policy.

 John Smith is a member of department2 so his mailbox will be assigned to the “Department2” address book policy..

The configuration is finished. Now verify the settings via Outlook.

Verify the settings

John Smith is logging on and calls the address book.

Joe Contoso is logging on and calls the address book.

Because the customer requirement for this scenario to work correctly was high, the project team decided to make the following configuration steps in order to bring the correct autodiscover functionality to mailbox switched users with an active account in the source forest.

The Exchange cmd-let “Export-AutodiscoverConfig” is available to export the autodiscover settings from an Exchange organization to a different forest, e.g. user forest. Via the following Exchange Management commands the settings from the target Exchange forest will be exported to the source forest. Once you have entered the credentials, please note the user for the target forest must be a member of the Enterprise Admins group. First step is to enter the target credentials:

$targetcredentials = get-credential

The following command will do the export of the autodiscover settings:

Export-AutoDiscoverConfig -TargetForestDomainController DomainController -MultipleExchangeDeployments $true -TargetForestCredential $targetcredentials

No message is returned. However we can look in ADSIEdit into the configuration naming context of the source forest to verify the exported SCP object. In ADSIEdit go to the configuration naming context. Open the properties of “CN=Microsoft Exchange Autodiscover” and choose properties.

The autodiscover information is exported to the source forest where Exchange 2007 is installed.

When we look at the security settings of the imported SCP object you can see the following security settings.

With the original security settings all users not only the mailbox switched users would receive the SCP configuration from the target Exchange organization. This is not wanted and therefore we have to remove the “Authenticated Users” setting and replace it with an already created security group named “Migrated".

Now the exported SCP object can only be read from the security group “Migrated”. This means all mailbox switched users must be a member of the security group “Migrated”. This can be easily achieved by querying the Quest database through a scheduled script.

Scenario computer is a member of target forest: In case the computer account is already a member of the target forest and the mailbox switched user is still active in the source forest, the user will get the SCP settings from the target forest which is fine in this scenario. But this means that a user who is not already mailbox switched using a computer which is joined to the target forest will also get the wrong autodiscover settings (here the user will get the target information). This can be solved in a similar way. Just export the autodiscover settings from source to target, remove the authenticated users from the SCP object as before and add a (domain local) security group with read permissions to the exported SCP object. Add all users from the source forest to this group which are not yet mailbox switched. Now every user from the source forest which is not yet mailbox switched but using a computer which is already migrated to the target forest will receive the autodiscover settings from the source Exchange organization.

Please note that the original SCP configuration will never be deleted or overwritten by the described process. The original SCP configuration can be found under the following location:

CN=<Exchange Server>,CN=Autodiscover,CN=Protocols,CN=<Exchange Server>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Exchange Organisation>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Root-Domain 

Ist für die Verteilerliste ein Owner eingetragen, so kann dieser auch nachdem die Verteilerliste hochgestuft worden ist über den Outlook Client die Verteilerliste bearbeiten.

Ein Problem entsteht allerdings wenn weitere Benutzer Rechte in Exchange 2003 bekommen haben die Verteilerliste in Outlook zu bearbeiten und dies nicht über eine Security Gruppe im "Managed by" Attribut durchgefuehrt worden ist. Um weitere Benutzer zum Bearbeiten der Mitgliederschaft in Exchange 2003 freizuschalten wird dies über die Security-Seite durchgeführt.

Diese beschriebene Vorgehensweise bei der Administration findet man recht haeufg. Unabhaengig ob die Verteilerliste bereits hochgestuft wurde, kann der Owner (ManagedBy) und alle Benutzer die obiges "WriteMembers" Recht gesetzt haben in Outlook die Verteilerliste bearbeiten, solange die Benutzer sich noch auf einem Exchange 2003 Server befinden. Wird nun die Verteilerliste auf Exchange 2010 hochgestuft, so wird der Owner übernommen und kann die Verteilerliste wie gewohnt bearbeiten. Auch sind die Benutzer, die über das "WriteMembers" Recht berechtigt worden sind weiterhin in der Lage die Verteilerliste zu bearbeiten.

Wird allerdings ein Benutzer, der über das "WriteMembers" Recht berechtigt worden ist auf Exchange 2010 verschoben, so erscheint auf einmal folgende Fehlermeldung innerhalb von Outlook.

Schaut man sich die Eigenschaften der hochgestuften Verteilerliste in der Exchange Management Console an, so sieht man lediglich, dass unter "Managed by" der Besitzer eingetragen ist, allerdings fehlt ein Eintrag für den Benutzer2, der zuvor innerhalb von Exchange 2003 über das "WriteMembers" Recht berechtigt worden ist.

Sind mehr als nur ein paar Verteilerlisten auf die beschriebene Art berechtigt worden, so hat man als Administrator mehr und mehr Probleme, je mehr Verteilerlisten und Benutzer nach Exchange 2010 verschoben werden. Um dieses Problem zu lösen kann man folgendermassen vorgehen:

1. Auslesen des "WriteMembers" Recht aller Verteilerlisten.

2. Hochstufen der Verteilerlisten auf Exchange 2010.

3. Nachträgliches hinzufügen aller Benutzer die "WriteMembers" gesetzt haben unter dem Owner Attribut der Verteilerliste.

 Über die folgende Query kann man das Recht "WriteMembers" innerhalb der Exchange Management Shell auslesen:

get-distributiongroup * | get-adpermission | Where-object {($_.AccessRights -eq 'WriteProperty' -and $_.Properties -like '*Member*' -and $_.User -like 'ACME\*' -and $_.User -notlike 'ACME\Exchange Wi*')}|fl user,id*

Der Domänenname muss angepasst werden und gegebenenfalls müssen diverse nicht interessante Gruppen wie die Exchange Windows Permissions ausgeblendet werden.

Um nun alle erwähnten Probleme zu lösen, kann man über ein kleines Exchange Management  Shell Skript die Verteilerlisten auf Exchange 2010 hochstufen und alle Benutzer, die nur über das "WriteMembers" Recht berechtigt worden sind unter dem "Managed by" Feld eintragen.

$user = get-distributiongroup verteiler1| get-adpermission | Where-object {($_.AccessRights -eq 'WriteProperty' -and $_.Properties -like '*Member*' -and $_.User -like 'ACME\*' -and $_.User -notlike 'ACME\Exchange Wi*')}|select user
del datei.txt
$User > datei.txt
$file = get-content datei.txt

$index=0

$user1=$file[$index]

While(1)
{
 if ($user1 -eq $null)
 {
  break
 }
 if ($user1 -like "ACME*")
 {

$t = get-user $user1.Replace(" ","")

set-distributiongroup -id Verteiler1 -BypassSecurityGroupManagerCheck  –Confirm:$false  -ManagedBy ((get-distributiongroup Verteiler1).Managedby + $t.DistinguishedName)

 }
 write-output $user1
 $index=$index+1
 $user1=$file[$index]
}

Das Skript soll lediglich zeigen wie die Vorgehensweise funktionieren kann. Will man das Skript für alle Verteilerlisten verwenden, muss es entsprechend angepasst werden.

Bei dem ersten Aufruf des Skripts sieht man, dass der Benutzer1 als bereits schon existierend einen Fehler produziert. Wird das Skript ein zweites mal aufgerufen, sieht man nun die gleiche Fehlermeldung für den Benutzer2 , der ja nur über das "WriteMembers" Recht in Exchange 2003 berechtigt gewesen ist.

 Überprüft man die Einträge in der Exchange Management Console, so sieht man nun zwei Einträge unter dem "Managed by" Attribut.

Der Directory Connector ist Bestandteil der CMN 3.x Coexistence Manager Suite von Quest. Der Connector synchronisiert die Verzeichnisse zwischen Exchange 2010 und Lotus Notes Domino. In der Vergangenheit konnte für diesen Verzeichnisabgleich auch der Microsoft Exchange "Lotus Notes 2003 Connector for Messaging and Directory Synchronization" verwendet werden. Mit Exchange 2007 wurde von Microsoft die Microsoft Transporter Suite für Exchange 2007 bereitgestellt. Die Microsoft Transporter Suite wird allerdings nur für Exchange 2007 unterstützt.

Beide Tools von Microsoft haben das Message Routing entweder über das Lotus Notes Routing oder über SMTP realisiert. Da der alte  "Lotus Notes 2003 Connector for Messaging and Directory Synchronization" immer noch im Einsatz sein kann, kommt man möglicherweise nicht darum, sich Gedanken zu machen, wie man diesen alten Connector ablösen kann. Denkt man über die Verwendung des Directory Connectors von Quest CMN 3.x Coexistence Manager nach, stellt sich die Frage wie man die alten Kontakte im Active Directory so aktualisieren kann, das der Directory Connector von Quest diese übernehmen kann, ohne die alten Kontakte zu löschen und durch den Directory Connector von Quest neu anlegen zu lassen.

Will man den Directory Connector von Quest einsetzen sind einige Schritte zu testen und umzusetzen, damit eine Neuerstellung der Kontakte im Active Directory verhindert werden kann.

Der Quest Directory Connector legt eine OU mit dem Namen CMN an. Alle Notes User würden innerhalb dieser OU neu angelegt werden. In der Abbildung sieht man die OU, sowie ein paar alte Kontaktobjekte, die durch den Exchange 2003 Lotus Notes Connector angelegt worden sind.

Die alten Kontakte haben im TargetAddress Attribut eine Lotus Notes Proxy Adresse. Nur unter dem Attribut ProxyAddresses findet man auch die SMTP Adresse, die zu dem Notes Kontakt gehört.

Wird nun der Directory Connector von Quest gestartet legt dieser keine Kontakte in der OU CMN an, da die SMTP Adressen bereits auf den alten Kontaktobjekten vorhanden sind. Allerdings werden die alten Kontaktobjekte auch nicht übernommen. Um dies zu realisieren muss in einem ersten Schritt die Notes Adresse unter dem Attribut TargetAddress auf die SMTP Adresse des Notes Users umgestellt werden.

 Die folgende Abbildung zeigt dies für ein Objekt beispielhaft:

Verschieben des modifizierten Kontaktobjekts in die OU CMN

Das Ändern des Attributes TargetAddress auf dem alten Kontaktobjekt alleine reicht nicht aus, damit der Directory Connector von Quest diesen übernimmt. Damit dies funktioniert muss das Kontaktobjekt in die OU von Quest also CMN verschoben werden. Die nächste Abbildung zeigt das Kontaktobjekt in der CMN OU bevor der Connector von Quest gestartet worden ist.

Eine Sychronisation mit dem Directory Connector von Quest Notes->Exchange starten:

Nachdem das TargetAddress Attribut auf die SMTP Adresse geändert worden ist und das Objekt in die CMN OU verschoben worden ist, wird der Connector von Quest in Richtung Notes->Exchange einmal gestartet. Das Ergebnis sieht dann wie in der folgenden Abbildung aus:

Jetzt hat der Directory Connector von Quest das Kontaktobjekt erkannt und auch entsprechend aktualisiert. Bei einer größeren Menge von Kontaktobjekten ist es am besten den gesamten Vorgang zu skripten anstatt die Änderungen manuell vorzunehmen.

Folgende Liste beinhaltet alle Rollen, die in der Default Role Assignment Policy enthalten sind:

• MyBaseOptions
• MyContactInformation
• MyVoiceMail
• MyTextMessaging
• MyDistributionGroupMembership  

Über die Shell sieht man welche Rollen dazugehören

Anpassen der Default Role Assignment Policy

Unterschiedliche Organisationen haben unterschiedliche Anforderungen, welche Einstellungen geändert werden dürfen bzw. welche Einstellungen überhaupt sichtbar seien sollen.

Die vorhandene Default Role Assignment Policy erlaubt es dem Benutzer über den Exchange Control Panel ECP die Attribute wie z.B. street, city, zip, region und office selber zu ändern. Auch können die Attribute für die Telefonnummern eigenständig hierüber durch den jeweiligen Benutzer geändert werden.

Unter den Optionen ist es auch möglich Einstellungen für Gruppen, Mobile Geräte und SMS vorzunehmen.

Um eine neue Assignment Policy zu erstellen öffnet man eine Exchange 2010 Management Shell. Der Benutzer muss Mitglied der Gruppe "Organization Management" sein.

Um bei Forests, die mehr als nur eine Domäne haben die Cmd-Lets erfolgreich über die Exchange Management Shell absetzen zu können empfiehlt es sich den View für die Shell auf den kompletten Forest zu setzen.

Set-ADServerSettings –ViewEntireForest $true

Nun wird eine Management Rolle erstellt und von der MyBaseOptions Rolle abgeleitet:

New-ManagementRole “MyCustomBaseOptions” –Parent MyBaseOptions

Um die Einstellungen für Mobile Geräte zu entfernen gibt man folgende Befehle in der Shell nacheinander ein:

Get-ManagementRoleEntry “MyCustomBaseOptions\Get-ActiveSyncDevice” | Remove-ManagementRoleEntry

Get-ManagementRoleEntry “MyCustomBaseOptions\Get-ActiveSyncDeviceStatistics” | Remove-ManagementRoleEntry

Get-ManagementRoleEntry “MyCustomBaseOptions\Clear-ActiveSyncDevice” | Remove-ManagementRoleEntry

Jetzt kann die neue Management Role Policy erstellt werden.

New-RoleAssignmentPolicy –name “NewPolicy” –Roles MyCustomBaseOptions

Um die neue Role Assignment Policy als default zu kennzeichnen wird folgender Befehlt in der Shell abgesetzt:

Set-RoleAssignmentPolicy “NewPolicy” –isdefault:$True

Jetzt bekommt jede neu erstellte Exchange 2010 Mailbox die Policy "NewPolicy" zugewiesen. Um die neue Policy bereits existierenden Benutzern zuzuweisen gibt es entweder die Möglichkeit dies über die Exchange Management Console durchzuführen oder über die Exchange Management Shell:

Wie sehen die Optionen jetzt für den Benutzer aus?

Auch sind keine Attribute editierbar, die zuvor geändert werden konnten:

Um die Einstellungen für Mobile Geräte wieder zu aktivieren, muss man lediglich die zuvor entfernten RoleEntries wieder hinzufügen:

Add-ManagementRoleEntry –identity “MyCustomBaseOptions\Clear-ActiveSyncDevice” –confirm:$false

Add-ManagementRoleEntry –identity “MyCustomBaseOptions\Get-ActiveSyncDeviceStatistics” –confirm:$false

Add-ManagementRoleEntry –Identity “MyCustomBaseOptions\Get-ActiveSyncDevicve” –confirm:$false

Wie sehen die Optionen jetzt für den Benutzer aus?

Wie man sieht sind die Möglichkeiten sehr variabel. Es können unterschiedliche Role Assignment Policies für unterschiedliche Benutzergruppen erstellt werden, um den jeweiligen Anforderungen gerecht zu werden.

Damit über die Exchange Management Shell ein Import von PST-Dateien vorgenommen werden kann, ist es notwendig zuvor eine entsprechende Sicherheitsgruppe im Active Directory anzulegen. Dies kann über den Exchange Control Panel ECP durchgeführt werden. Alternativ geht dies natürlich auch über die Exchange Management Shell. Selbst Mitglieder der höchsten Exchange Gruppe „Ogranization Management“ können per default keinen Import oder Export anstossen.

Um diese neue Grupppe anzulegen meldet man sich an Outlook WebApp an mit einem Account, der das Echange Recht hat RBAC Gruppen zu administrieren. Nun wechselt man in die Optionen zu dem Punkt „Meine Organization verwalten“. Hier geht man auf die Einstellungen für „Rollen und Überwachung“.

·         Erstellen einer neuen Rollengruppe z.B. „ImportExport-PST“.

Die folgende Abbildung zeigt die Gruppe und deren Rollen, die für das Importieren bzw. Exportieren notwendig sind. Nun muss nur noch der Account hinzugefügt werden, der die PST-Dateien in die Mailboxen/Archive importieren soll. In diesem Beispiel ist es der Administrator.

Damit eine geplanter Import erfolgreich verlaufen kann, muss die Exchange Mailbox bereits existieren bzw. ein Archiv muss angelegt sein, falls die Migration direkt in das Exchange Archiv geschehen soll.

Um eine Migration zu starten, wird eine Exchange Management Shell auf einem Exchange Mailbox Server geöffnet. Dies muss nicht der Mailbox Server sein auf dem sich die Archive befinden. Es muss auch kein Outlook auf dem Exchange Server installiert sein. Nur das Service Pack 1 für Exchange 2010 wird benötigt.

Über das Exchange Management Cmd-Let New-MailboximportRequest wird der Import einer PST-Datei vorgenommen. Wird der Parameter -isarchive verwendet, werden die Daten in das Archiv der Mailbox importiert, ohne Angabe dieses Parameters wird der Inhalt in die Exchange Mailbox importiert. Der Parameter -FilePath gibt den Speicherort der PST-Datei an. Dies kann zum Beispiel wie folgt aussehen: \\Server\FileShare\Dateiname.pst. Der Parameter -Mailbox beinhaltet den Exchange Alias der Zielmailbox. Über den Parameter -TargetRootfolder wird bei Bedarf ein bestimmter Ordner angelegt unter dem alle Daten aus der PST inklusive der Ordnerstruktur angelegt werden.

Wie man hier sieht, wird der Import nicht direkt gestartet, sondern gequeued. Über das Exchange Cmd-Let Get-MailboxImportRequest können alle Requests und der jeweilige Status abgerufen werden.

Über das Exchange Cmd-Let Remove-MailboxImportRequest können die bereits durchgeführten ImportRequests bei Bedarf gelöscht werden.

Um diesen Prozess zu automatisieren, muss lediglich eine Input-Datei erstellt werden, in der alle PST-Dateien und der jeweilige Exchange Alias pro Zeile aufgelistet sind. Am einfachsten ist es, wenn alle PST-Dateien im gleichen Verzeichnis/Share zur Verfügung gestellt werden.

Beispiel Inputdatei:

a.kapteina,kapteina.pst

user2,user2.pst

user3,user3.pst

Wie kann via Skript dafür gesorgt werden, dass der jeweilige Benutzer über den Verlauf der Importierung bzw. über den Abschluß informiert wird?

Über das Cmd-Let Send-MailMessage:

--------------------------------- Beispielcode ----------------------------------------------------------------------------------

$data = get-content inputfile.txt

$emailbody  = get-content emailbody.txt | out-string

$utf8 = New-Object System.Text.utf8encoding

$user=$data[$index].split(",")

$MailboxUser = get-mailbox $user[0]

$YourFilePath = "\\Server\C$\Share\" + $User[1]

New-MailboxImportRequest -isarchive -FilePath $YourFilePath -Mailbox $user[0] -TargetRootfolder Import

------------------------------ Beispielcode Ende --------------------------------------------------------------------------------

Damit der Emailversand auch erfolgreich funktionieren kann, muss ein Receive Connector auf dem Server SMTPServer angelegt werden, der anonymen Zugriff für eine ausgewählte IP Adresse gestattet. Der Absender wird gegenüber der GAL aufgelöst, wenn der Receive Connector auf "Externally secured" eingestellt wird.