Artikel von Microsoft: http://technet.microsoft.com/en-us/library/cc816788%28v=ws.10%29.aspx

Allow Anonymous LDAP Binding to an AD LDS Instance

Active Directory Lightweight Directory Services (AD LDS) does not accept anonymous bind requests by default. You can use this procedure to enable anonymous Lightweight Directory Access Protocol (LDAP) operations in AD LDS. However, you must set the seventh character of the dsHeuristics value to 2. In addition, assign permissions so that anonymous users have access to the appropriate objects in the directory. To grant the Read permission on all objects in a given directory partition to anonymous users, you can simply add the built-in security principal Anonymous (from the local computer) to the Readers group on that directory partition.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To allow anonymous LDAP binding to an AD LDS instance

Click Start, point to Administrative Tools, and then click ADSI Edit.

Connect and bind to the configuration directory partition of the AD LDS instance on which you want to allow anonymous LDAP binding. For more information, see Manage an AD LDS Instance Using ADSI Edit.

In the console tree, double-click the configuration directory partition (CN=Configuration,CN={GUID}), double-click the services container (CN=Services), double-click the Windows NT container (CN=Windows NT), right-click the directory service container (CN=Directory Service), and then click Properties.

In Attributes, click dsHeuristics, and then click Edit.

In Value, modify the value of the seventh character in the attribute (counting from the left) to 2, as follows:

0000002001001

Click OK twice.

Meine Überlegungen zur Coexistenz Ex2007/Ex2010 und OWA Zugriffe.

Exchange 2010 und Exchange 2007 existieren während einer Migrationsphase parallel. OWA Zugriffe werden über den TMG direkt an den Exchange 2010 CAS Server geroutet.

Durch Redirect am CAS Server besteht die Möglichkeit, die Client Zugriffe von OWA auf den Exchange 2007 umzuleiten, wenn das Postfach noch nicht migriert wurde. Der Exchange 2010 CAS Server liefert dem TMG dann einen 302 (Permanent redirect) und liefert den URL String zurück, wohin der Client sich connecten soll an den Browser. (ExternalURL am Exchange 2007 kann gesetzt werden, diese URL muss aber auch öffentlich erreichbar sein.)
Beispiel: Public OWA URL lautet: https://owa.firma.tdl/owa Am TMG werden diese Anfragen an den Exchange 2010 CAS geroutet. Der Exchange 2010 CAS stellt fest, dass das Postfach auf Exchange 2007 liegt und sucht den Exchange 2007 CAS Server, der die gleiche Authentifizierung hat um die Anfrage dorthin umzuleiten. Wenn in am Exchange 2007 CAS in der ExternalURL kein Eintrag steht, wird der InternalURL Eintrag verwendet.
Problem: Dieser ist typischerweise nicht veröffentlicht, weil es der Hostname des CAS Servers ist.
Problem2: In der ExternalURL kann eine öffentliche URL angegeben werden, die dann auch über den TMG geroutet werden müssen. Der User sieht in seinem Browser dann auch die “alte” URL und nicht die von ihm eingegebene OWA-Adresse.
Problem3: Im Zertifikat muss auch die “alte” URL eingetragen sein.

Lt. diesem Artikel: http://technet.microsoft.com/en-us/library/bb310763.aspx wird Proxying zwischen Exchange 2010 CAS und Exchange 2007 CAS nicht unterstützt.

Bb310763.important(en-us,EXCHG.141).gifImportant:
An Exchange 2010 Client Access server will never proxy Outlook Web App requests to an Exchange 2007 Client Access server in the same Active Directory site. All requests within the same Active Directory site are redirected to an Exchange 2007 Client Access server, using either the InternalURL or ExternalURL properties for Client Access server, depending on which properties are configured.

 

Das gefällt mir so nicht, weshalb ich am TMG gerne zwei Regeln für OWA eintrage. Eine Regel für Exchange 2010 Mailboxen, eine weitere Regel für Exchange 2007 Mailboxen.

Die Reihenfolge der Regeln ist wichtig. Erst die Exchange 2010 Mailbox-Regel, danach die Exchange 2007 Mailboxregel. In der Exchange 2010 Mailboxregel wird dann eine Gruppenmitgliedschaft abgefragt. Trifft die Mitgliedschaft zu, dann zieht die Exchange 2010 Mailboxregel, trifft die Mitgliedschaft nicht zu, dann zieht die Exchange 2007 Regel.

Ja, dazu ist es nötig, migrierte User in die Gruppe für Exchange 2010 Mailboxen aufzunehmen. Da ich zu 90% Migrationen mache, die per Script ablaufen, ist es kein Problem, beim Erzeugen des Move-Requests auch die Gruppenmitgliedschaft zu pflegen.

Vorteil1: Der User sieht in seiner Adresszeile immer “seine” OWA-URL die er auch eingegeben hat,
Vorteil2: Das Zertifikat kann weiterverwendet werden.
Vorteil3: Der interne Name des Exchange 2007 Servers muss nicht veröffentlicht werden.

Wenn die Migration erledigt ist, lösche ich einfach die Exchange 2010 Mailbox-Gruppe und passe die Regel am TMG an.
Teilweise verwenden die Kunden jedoch die Gruppe weiter, um den Active-Directory-Administratoren eine einfache Möglichkeit zu bieten, den Zugriff auf OWA per Gruppenmitgliedschaft zu steuern. Dann muss dann keine Exchange Konsole gestartet werden um OWA zu regelemntieren.

Es gibt sicherlich auch weitere/andere Lösungen, aber mit dieser Lösung bin ich bisher ganz gut gefahren.

Matthias

Im Anwendungslog steht folgender Fehler:

Details
Product: Exchange
Event ID: 4002
Source: MSExchange Availability
Version: 8.0
Symbolic Name: ProxyWebRequestFailed
Message: Process %1: %2 failed. Caller SIDs: %3. The exception returned is %4. Make sure that Active Directory site/forest containing the user mailbox has at least one local Exchange 2007 server running Exchange Availability service. Turn up logging for MSExchange Availability service and test basic network connectivity.
 

Im Text kommt zus. folgender Text vor: FreeBusyViewOptions.TimeWindow is too long.

Auf den CAS 2007 Servern muss im IIS folgender Eintrag hinzugefügt werden:

Expand the Default Website
Select the EWS virtual directory.
Double click Applciation Settings
Add a new application value:
Name: maximumQueryIntervalDays
Value: 62
Click OK..

Make the change on all the 2007 CAS servers. You should see the 4002 event go away.

Als Gedächtnisstütze hier mal die vorgehensweise wie ein Postfach oder Postfachinhalte aus der RDB (Recovery Datenbank) wiederhergestellt wird:

  • Recovery DB anlegen:

http://technet.microsoft.com/en-us/library/ee332321.aspx

New-MailboxDatabase -Recovery -Name RDB2 -Server EX2010MBXServer  -EdbFilePath “D:\MDBDATA\RDB\DB\RDB2.EDB” -LogFolderPath “D:\MDBDATA\RDB\LOG”

  • Restore der Datenbank mit dem Backup-Programm in die RDB durchführen (dauert je nach DB Größe sehr lange)

Vorgehen bei TSM:
Beim TSM muss das Restore-Ziel ausgewählt werden, sonst steht nämlich die original Datenbank drinnen, was nicht so gut ist. Passiert nichts, geht aber auch nicht und die Zeit kann man sich sparen.
Restore mit Logfiles (das TSM macht den RollForward in der RDB) und den ESEUtil um einen Cleantshutdown zu haben.
Andere Backuplösungen:
<wird bei Erfahrung gefüllt, bzw. lasst mich wissen, worauf bei anderen Lösungen geachtet werden muss>

  • Daten wiederherstellen

Restore Data Using a RDB:
http://technet.microsoft.com/en-us/library/ee332351.aspx
New-MailboxRestoreRequest: http://technet.microsoft.com/de-de/library/ff829875.aspx

Wichtig:
The database must be in a clean shutdown state. Because an RDB is an alternate restore location for all databases, all restored databases will be in a dirty shutdown state. You can use Eseutil /R to put the database in a clean shutdown state.
Get-MailboxStatistics -Database RecoveryDB.
–> Das hat TSM für uns erledigt, ansonsten von Hand die DB in einen Clean Shutdown versetzen.

  • Inhalt der RDB ansehen/Mailbox GUID ermitteln

Die Mailbox-GUID ermitteln mit: Get-MailboxStatistics -Database “Archiving Database 1″ | list displayname,identity
(MailboxGUID in Zwischenablage kopieren)

  • Komplettes Postfach zurückspielen

New-MailboxRestoreRequest -SouceDatabase DB1 -SourceStoreMailbox 1d20855f-fd54-4681-98e6-e249f7326ddd -TargetMailbox Scott
(Hier die Mailbox GUID eintragen)

  • Oder Teile aus einem Postfach zurückspielen (Unterordner, Kalender, o.ä.)

New-MailboxRestoreRequest -SourceDatabase Recoverydb -SourceStoreMailbox “GUID for DB” -TargetMailbox “usern name” -TargetRootFolder “foldertorestoreto
Mailboxguid “801f870d-1ef2-4326-97f9-7bc475df055b”
(Exchange 2010 RTM:
Restore-Mailbox -Identity “Alex Heyne” -RecoveryDatabase RecoveryDB -RecoveryMailbox “Alex Heyne” -TargetFolder Restore
)

  • Beispiel um den Inhalt des Postfaches in einen Unterordner zurückspielen (Mailbox Limits beachten!)

New-MailboxRestoreRequest -SourceDatabase RDB2 -SourceStoreMailbox 801f870d-1ef2-4326-97f9-7bc475df055b –TargetMailbox thomas.mustermann@parmalat.nz.com -TargetRootFolder “Restore vom 27.01.2012″
“801f870d-1ef2-4326-97f9-7bc475df055b”

 

Outlook verwendet für den Zugriff auf Outlook Anywhere (RPCoverHttp) immer die RPC Komponente des Betriebssystems.

Hier gibt es zwischen Windows XP und Vista/Windows 7 Unterschiede im Verhalten.

Ein Grund, warum Windows XP sich nicht verbinden kann, könnte auch an einer Veröffentlichungsregel im TMG liegen. In einer Konstellation, wenn mehrere CAS Server verwendet werden (NLB Verbund), dann werden diese als Web-Farm im TMG als Ziel eingetragen.

Hier gibt es einen Load Balancing Mechanismus, der entweder Cookie Based oder Source IP Based eingetragen wird.

- Cookie Based für genattete Umgebungen, d.h. am TMG kommen alle mit der gleichen IP an
- Source IP Based, d.h jeder Client kommt mit seiner IP an

Problem bei Cookie Based: Windows XP kann damit nicht umgehen. Das bedeutet, es geht für Windows XP nur mit Source IP.

Was aber passiert, wenn die externen Clients genattet sind und alle mit der gleichen IP ankommen? Das funktioniert grundsätzlich auch mit Source IP Routing, jedoch ist dann kein Load Balancing mehr gegeben. D.h. man MUSS NAT auf Source Transparent Routing umstellen.

Wenn es nicht daran lag, dann treffen vielleicht die vielen anderen Artikel, die bei google zu finden sind, zu.

 

 

Exchange Active Sync funktioniert nicht, wenn die Vererbung bei diesen Usern unterbrochen ist.
Inherit from parent aktivieren, dann geht es wieder….

der AdminSDHolder Background Prozess läuft alle 60 Minuten im Hintergrund und ändern die Berechtigungen auf dem/den Objekt/en

http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

http://technet.microsoft.com/en-us/library/dd439375(EXCHG.80).aspx

Update: So können die Accounts ermittelt werden, welche unter Kontolle durch den AdminSDHolder fallen:

Get-ADUser -LDAPFilter “(objectcategory=person)(samaccountname=*)(admincount=1)”|ft

Das Attribut admincount auf 0 setzen und anschließend die Vererbung der Rechte aktivieren. Generell sollten Admin Accounts nicht Mailenabled sein. Dafür hat man doch seinen Standard Account!

 

Set-User -Identity kweku@fabrikam.com -LinkedMasterAccount $null

Nach der Migration wird ggf. das OLK Profil nicht zeitnah angepasst (neuer Server).
Das liegt am Cache des IS und Outlook (http://social.technet.microsoft.com/Forums/en-ZA/exchange2010/thread/cdb55dea-14dd-49b4-8ee3-1013f6355a47 )

Welcher Cache genau weiß ich nicht – geht aus dem Artikel nicht hervor.
Den IS neu starten ist keine Option.

Diese Anleitung half bei mir:

http://www.prevx.com/blog/140/Black-Screen-woes-could-affect-millions-on-Windows–Vista-and-XP.html

Update 25.03.12 nachdem die o.g. URL das Programm nicht mehr zur Verfügung stellt, hier die Lösung die bei mir half:

http://answers.microsoft.com/en-us/windows/forum/windows_7-system/windows-7-start-up-problems-with-black-screen-and/4150da7f-3386-41dd-883f-87d1c9d67647

 

Das half bei mir:

1.) Die Treiber für die Grafikkarte aktualisieren unter C:\Program Files\Common Files\vmware\drivers\video (evtl. auch \wddm_video)
2.) Reboot
3.) Screen-Resulotion/Advanced Settings/Troubleshoot/ Beschleuniger auf FULL setzen

Nur mal so als Gedankenstütze: (http://social.technet.microsoft.com/wiki/contents/articles/exchange-server-and-update-rollups-builds-numbers.aspx)

 

GCM exsetup |%{$_.Fileversioninfo}

In Exchange 2010 gibt es nun die Möglichkeit, den Abwesenheitsassistenten (OOF Out of Office) zentral zu steuern. Das ist sehr hilfreich, wenn man sich nicht Vollzugriff auf das Benutzerpostfach aneigenen möchte – nur um den Abwesenheitsassistenten zu aktivieren.
Damit das auch durch den Helpdesk bedient werden kann, habe ich da mal eine GUI außen herum gebastelt….
Matthias

Aus der Exchange 2010 EMC kann auf ein Postach relativ einfach das Recht Full Access gesetzt werden (Manage Full Access Permissions). Durch verwenden der Konsole wird in diesem Postfach das Attribut 

msExchDelegateListLink

mit dem DistinguishedNamen des Berechtigen Users gefüllt. Damit wird dem User beim Starten seines Outlooks automatisch dieses Postfach hinzugemappt, auf dem er Vollzugriff hat.

Feine Sache - wenn man es möchte. Durch entfernen des DN in diesem Attribut kann man steuern, ob das Postfach automatisch gemappt werden soll.

Steve Goodman hat auch einen ausführlichen Artikel dazu geschrieben.

SnapShots belegen Platz. Damit eine Partition nicht volläuft, sollte mittels vssadmin.exe das SnapShot Volume richtig konfiguriert werden.
Dazu verwende ich den vssadmin.exe:

Mit dem Kommando

vssadmin Add ShadowStorage /For=C: /On=<Ziel-Partition> /MaxSize=2GB

setze ich die Größe, welche für Snapshots von Laufwerk C: verwendet werden sollen. Das schöne daran ist, dass ich mich nicht um alte Snapshots kümmern muss. Sollte der Platz im ShadowStorage nicht mehr ausreichen, dann wird automatisch der älteste Eintrag entfernt.

Nun zum eigentlichen SnapShot, der mittels NTDSUtil.exe erzeugt wird.

Mit diesem Kommand wird ein SnapShot vom  Active Directory erzeugt:

ntdsutil snapshot “activate instance ntds” create q q

erzeugen wir den SnapShot im angegebenen ShadowStorage Bereich.

Ich verwende dazu das “Directory Service Comparison Tool” von Frederik Lindström.

Voraussetzung: Ein SnapShot muss vorhanden sein. (Hier gehts zum SnapShot Thema)

Verwenden Sie Ntdsutil um einen SnapShot zu mounten:

Im Explorer taucht nun der SnapShot als Linked Volume auf:

Suchen Sie nun die Datei ntds.dit (<SnapShotVolume>\Windows\NTDS\ntds.dit)

Übernehmen Sie den Pfad incl. Dateiname um diese Active Directory Kopie zu mounten.

Verwenden Sie dsamain.exe um die Kopie zu mounten.

Der Befehl lautet :

Dsamain.exe /DBPath “<Pfad zur NTDS Kopie Datei>” /ldapPort 16000

Starten Sie nun eine MMC.EXE und fügen das SnapIn „Directory Service Comparison Tool“ hinzu.

Verbinden Sie sich mit dem aktuellen Domaincontroller und der Kopie, in dem Sie den Port 16000 verwenden, wie im dsamin Programm angegeben.

Die beiden Verzeichnisse werden nun miteinander verglichen und die Änderungen (Change, Add, Delete) werden angezeigt.

Durch markieren des entsprechenden Attributes können Sie den geänderten Wert durch die Information aus dem SnapShot wieder herstellen.

Wenn der Restore Vorgang beendet ist, beenden Sie die MMC Konsole.

Beenden Sie die gemountete Kopie des Active Directories (im dsamain) indem Sie STRG + C drücken.

Verwenden Sie das ntdsutil um den gemounteten SnapShop zu dismounten. Geben Sie dazu im ntdsutil folgendes ein:

  • „List mount“ um eine Liste der gemounteten SnapShots anzuzeigen
  • Unmount <Nr des SnapShots>

Das Attribut “BytesTransferredPerMinute” ist nur während eines Moves/Export gefüllt. Nach erfolgreichen Move/Export ist das Attribute wieder leer. Eine Statistic über die Performance der bereits verschobenen Mailboxen würde mich aber schon interessieren um daraus Rückschlüsse für weitere Move/Export-Requests ziehen zu können.

Ich habe mir dazu ein Script geschrieben, welches den Wert berechnet (Es kann natürlich beliebig erweitert werden):

Function Get-MailboxMoveStatistics {

$Requests = Get-MoveRequest|get-MoveRequestStatistics 
foreach($Request in $Requests ) {

$MBXSize  = $Request.BytesTransferred
$Duration = $Request.OverallDuration        
#-> Bei Werten kleiner 1 MB ist das Ergebnis immer 0. Deshalb neuer Ansatz
#     $MBAvg = $MBXSize.ToMB() / $Duration.TotalMinutes          
$MBAvg = ($MBXSize.ToBytes() / $Duration.TotalMinutes) / 1MB

New-Object PSObject -Property @{

Alias = $Request.Alias
MBXSize = $Request.BytesTransferred
OverallDuration = $Request.OverallDuration
“MBTransferredPerMinute” = “{0:n2}” -f $MBAvg   

         
}

}

}

Damit können die Größen der Datenbanken ermittelt werden. Wenn ein vordefiniertes Limit erreicht ist, dann wird ein Eventlog geschrieben, dass eine weitere Datenbank nötig ist.

Function Get-DatabaseStatistics { 
     $Databases = Get-MailboxDatabase -Status
     $Result = “”

     foreach($Database in $Databases) { 
         $DBSize = $Database.DatabaseSize 
         $MBCount = (Get-Mailbox -Database $Database.Name).Count 
         $MBAvg = $DBSize.ToBytes() / $MBCount            

 $Result += “Server`t`t`t: ” + $Database.Server.Name+[char]13+[char]10
 $Result += “Databasename`t`t: ” + $Database.Name+[char]13+[char]10
 $Result += “MailboxCount`t`t: ” + $MBCount +[char]13+[char]10
 $Result += “DatabaseSize (GB)`t`t: ” + “{0:n2}” -f ($DBSize.ToBytes() / 1GB)  +[char]13+[char]10
 $Result += “WhiteSpace (MB)`t`t: ” + “{0:n2}” -f ($Database.AvailableNewMailboxSpace.ToBytes() / 1MB)  +[char]13+[char]10
 $Result += “AverageMailboxSize (MB)`t: ” + “{0:n2}” -f ($MBAvg / 1MB)  +[char]13+[char]10
 $Result += “LastFullBackup`t`t: ” + $Database.LastFullBackup        +[char]13+[char]10

 $result +=  [char]13+[char]10

     } 
     return $Result

 } 
  
Function Get-DBSize($SITE){
 $Faktor        = 1GB      # Darstellung in MB oder GB….
 $MaxDBSize     = (100 * $Faktor)    # Maximale Größe der Datenbank in MB oder GB je nach Faktor, Default 100 xB….
 $HighWaterMark = ($MaxDBSize * 0.8 / $Faktor)   # Ab wann soll gewarnt werden (80% default)
 $DBCounter     = 0
 $lNewDB=$TRUE
 $Result = “”
 
 $MaxDBSize     = (100 * $Faktor)/$Faktor

 
 #Sucht nur ZDx Datenbanken
 ForEach($Database in Get-MailboxDatabase ZD* -Status|Sort-Object Name)
 { $DBCounter = $DBCounter +1
  $DBSize        = ($Database.DatabaseSize.ToBytes() / $Faktor)
  # Passt in diese Datenbank noch eine Mailbox rein?
  
  write-host $Database.Name
  write-host $DBSize
  write-host $HighWaterMark
  if ($DBSize -lt $HighWaterMark)
  {              
   $lNewDB = $False   
   # Wenn noch eine reinpasst, dann muss keine NewDB angelegt werden ($False)
   break     
   # Schleife kann nun schon beendet werden
  }
 }
 # das neue Postfach hat in keine DB reingepasst, also muss eine neue DB angelegt werden
 if ($lNewDB -eq $True) {
  $Help= “Alle {2} -Datenbanken sind zu mehr als {0} % belegt. Maximale Datenbankgröße {1:n2} MB. Neue {2} -Datenbank wird benötigt.” -f $HighWaterMark, $MaxDBSize, $Site
#write-host $Help
write-eventlog -logname Application -source “MSExchangeStatistic” -eventID 997 -entrytype Warning -message $help

 }
}
Function SendMail($MessageBody){

 $emailFrom = From@domain.de
 $emailTo = Empfaenger@domain.de
 $subject = “Database Statistics”
 $body = $MessageBody
 $smtpServer = “Mailserver.domain.de”
 $smtp = new-object Net.Mail.SmtpClient($smtpServer)
 $smtp.Send($emailFrom, $emailTo, $subject, $body)
}

########################################################################################################################

$result = Get-DatabaseStatistics
write-eventlog -logname Application -source “MSExchangeStatistic” -eventID 998 -entrytype Information -message $result
SendMail($result)

Get-DBSize(“ZD”)
Get-DBSize(“VB”)

 exit

$emailFrom = “user@yourdomain.com”
$emailTo = “user@yourdomain.com”
$subject = “your subject”
$body = “your body”
$smtpServer = “your smtp server”
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($emailFrom, $emailTo, $subject, $body)

Get-OrganizationConfig |fl *tips*
MailTipsExternalRecipientsTipsEnabled : False
MailTipsLargeAudienceThreshold        : 25
MailTipsMailboxSourcedTipsEnabled     : True
MailTipsGroupMetricsEnabled           : True
MailTipsAllTipsEnabled                : True

Um die GroupMetrics wird benötigt, um die Anzahl der Mitglieder in einer Mailgruppe zu ermitteln. Um keine Online-Abfrage der Gruppenmitglieder machen zu müssen, wird jeden Tag um xx:xx Uhr die Liste der Gruppenmitglieder neu generiert. Dazu muss der MBX-Server konfiguriert werden:

Set-MailboxServer EXCH2010-SRV1 -GroupMetricsGenerationEnabled:$true

Der Dienst “Microsoft Exchange Service Host” ist dafür verantwortlich. Er kopiert das Ergebnis auf den/die CAS Server in das Verzeichnis %ProgramFiles%\Miccrosoft\Exchange Server\V14\ClientAccess\GroupMetrics.

Wenn man einem User das Recht genommen hat, an einen Empfänger Mails zu senden, erscheint dies ebenfalls als MailTips Meldung.
(Set-Mailbox UaserA -RejectMessageFromSendersOrMembers UserB bedeutet, dass UserB keine Mails mehr an UserA senden darf.)

Zusätzlich kann man sich selbst auch Custom MailTips erstellen:

(mit Set-Mailbox und Set-DistributionGroup)

Set-Mailbox UserB –Mailtip “Sind Sie sicher, dass sie mir eine Mail senden müssen ? :-)

Für die 64 Bit Umgebung gibt es auch eine Additional AccountInfo Property Page:

http://www.activedir.org/ACCTINFO2_64BIT.zip