Egy darabig nem ez volt a legfontosabb, de hát az ember szépre akarja reszelni a rendszerét, így ezt is kikerestem, megoldottam. A problémát az okozta, hogy a szerver nem tudja merre menjen kicsiny AD rendszerünkben és lassabban találja meg az infót, mint az EMC amennyit várni hajlandó.

Az aktuális beállításokra a Get-ADServerSettings kapcsoló által adott infók segítenek megjelennie.

[PS] C:\Windows\system32>Get-ADServerSettings | fl

RunspaceId                                 : 24e38aa9-d719-4708-b2e8-a423fb615dfb
DefaultGlobalCatalog                       : SERVER01.company.org
PreferredDomainControllerForDomain         : {}
DefaultConfigurationDomainController       : SERVER01.company.org
DefaultPreferredDomainControllers          : {SERVER01.company.org}
UserPreferredGlobalCatalog                 :
UserPreferredConfigurationDomainController :
UserPreferredDomainControllers             : {}
RecipientViewRoot                          : company.org
ViewEntireForest                           : False
Identity                                   :
IsValid                                    : True

A fentiekben a “hiányok” már érzékelhetőek is, azaz vár ránk a Set-ADServerSettings kapcsoló, amivel beállíthatjuk a számunkra szükséges értékeket.

NAME
    Set-AdServerSettings

SYNOPSIS
    Use the Set-AdServerSettings cmdlet to manage the Active Directory Domain Services
    (AD DS) environment in the current Exchange Management Shell session. The
    Set-AdServerSettings cmdlet replaces the AdminSessionADSettings session
    variable that was used in Microsoft Exchange Server 2007.

SYNTAX
  Set-AdServerSettings [-ConfigurationDomainController <Fqdn>] [-Confirm  
    [<SwitchParameter>]] [-PreferredGlobalCatalog <Fqdn>] [-RecipientViewRoot
    <String>] [-SetPreferredDomainControllers <MultiValuedProperty>]
    [-ViewEntireForest <$true | $false>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

  Set-AdServerSettings -PreferredServer <Fqdn>
    [-Confirm [<SwitchParameter>]] [-RecipientViewRoot <String>]
    [-ViewEntireForest <$true | $false>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

  Set-AdServerSettings –RunspaceServerSettings  
    <RunspaceServerSettingsPresentationObject> [-Confirm [<SwitchParameter>]]
    [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Amennyiben a fenti paramétersorral a dolgokat megfelelően beállítjuk, akkor a probléma megszűnik.

Get-Mailbox -Arbitration -Database db1 | New-MoveRequest -TargetDatabase db2

Ezt követően a dolog már minden gond nélkül a megszokott eljárásokkal lefolytatható volt.

   Ugrás a méretező excel tábla lelőhelyére

Véleményem szerint ezeket a méretezéseket el lehet fogadni mint kiinduló alap, s ha valaki olyan méretű rendszert csinál mint az MS-es kollégák akkor kell is, de azért lehetséges ésszel figyelembe venni a kapott eredményeket. Viszont ezek mint korrekt kiindulási alap elfogadhatóak, és ezek változtatása mindenkinek a saját businesse már.

A legegyszerűbb megoldás az Exchange 2010 konzolon a Move Request lehetőségek kihasználása, melyekből kétféle adódik jelenleg (Exchange 2010) számunkra:

• Local Move – Exchange Organizáción belüli mozgatás
• Remote Move – Eltérő erdőre való mozgatás

A fentiek alapján azt hiszem itthon inkább az első lesz a mindennapi változat.

Exchange Administrator

Az Exchange Administratorban jelöljük ki a számunkra lényeges postaládákat és a jobb egérgomb megnyomására megjelenő menüben válasszuk ki a szükséges mozgatás típust – pl. New Local Move Request.

A megjelenő varázslót értelem szerűen kattintsuk végig – annyira egyértelmű, hogy nem érdemes leírni és kifotózni – majd az egész végeredményeképpen a rendszer valamennyi feladatot a Move Request gyűjtőbe zsúfolja be és a továbbiakban itt követhetjük nyomon a dolgok alakulását.

Exchange Management Shell

Bár a fenti megoldás igencsak kényelmes, de vannak helyzetek ahol kimondottan előnyös, ha scriptből tudjuk elvégezni a dolgokat. A mozgatáshoz a következő két parancs lehet számunkra fontos:

• Mozgatás elindítása
  New-MoveRequest –Identity username –TargetDatabase “database name”
• Mozgatás állapota
  Get-MoveRequest [–Identity username]

http://isaserver.spaces.live.com/blog/cns!985DD920BD947A38!720.entry 

Potenciális Excange 2010 hibaforrásra szeretném felhívni a figyelmet:

• A PF storet nem tudod DAG-hoz rendelni
• OAB generálásra csak a Mailbox Role gépek képesek
• Ha minden Mailbox Role géped DAG tag, akkor hova teszed a PF adatbázist? 
  Válasz: teheted bármelyik gépre, de a DAG-hoz nem adhatod hozzá az adatbázist, ez eddig rendben is van
• Viszont ahhoz, hogy a PF-be tudja publikálni az OABGen Server az OAB-ot, legalább egy mount-olt Private IS kell
  Tehát, ha egy “passzív” DAG tagon van a PF, ahol nincs mountolt Private store, akkor nem fog menni az OAB Generálás

Többit lásd a fent hivatkozott cikkben.

Error:
Active Directory operation failed on <<DOMAIN CONTROLLER NAME>>. This error is not retriable. Additional information: The name reference is invalid.
This may be caused by replication latency between Active Directory domain controllers.
Active directory response: 000020B5: AtrErr: DSID-03152392, #1:
0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)

A value in the request is invalid.

Exchange Management Shell command attempted:
new-mailboxdatabase -Server ‘<<MAIL SERVER NAME>>’ -Name ‘Administration’ -EdbFilePath ‘E:\Administration\Administration.edb’ -LogFolderPath ‘E:\Administration’

Elapsed Time: 00:00:00

Mount Administration
Cancelled

Elsőre néztem, mint a moziban, hisz nem nagyon láttam mi is lehet a gond. Ezt követően nézmi túrás a neten és arra jutottam, hogy a szerverem nem tudja mely szerverek szolgálják, szolgálhatják ki.

Get-ADServerSettinngs | fl

Ennek beállítását ezután már egyszerű volt megoldani, csak egy egyszerű Power Shell parancs és megy is minden:

Set-ADServerSettings –PreferredServer [insert DC FQDN here]

A beállítást követően még egyszer ellenőriztem, hogy sikeres voltam-e, majd irány a MailBox DB létrehozása – és igen, így már minden megy rendesen.

Az egészet – természetesen – Power Shell-ből lehet végigcsinálni, így bár nem jelölöm, de minden ott történik. Amennyiben távolról kezeljük a szerverünket akkor a számunkra szükséges szerverhez kapcsolódjunk az Exchange Power Shell-el. Nézzük tehát mi a teendőnk!

Aktuálisan elérhető Certificate-k lekérdezése

Első lépésben ellenőrizzük le a már meglévő certificate-ket amik a rendszerben aktuálisan elérhetőek.

[PS] C:\Windows\system32>Get-ExchangeCertificate

Thumbprint                              Services Subject

———-                              ——– ——-

6CFEB76CB02E4515F52E4D03E7621882BED59163 ……  CN=srvxch1.domain.hu

6D580B3EDBBFA408B86F713FE93EB5D61C3CDDD8 ……  CN=SRVXCH1.domain.hu

29FAB7D0FB92673D1A9245717F76548D4B82FBEE ……  CN=SRVXCH1.domain.hu

7E4914F1EE5050C462D4CC2916E03BBF9212FAC2 IP.WS.  CN=SRVXCH1

Új kulcs igénylése, generálása, betöltése

1. Kérés létrehozása

Amennyiben ezek között nincs a számunkra szükséges kulcs, akkor nincs mese, újat kell kérni. Mi a teendő? Egy szép hosszú sor végiggépelésével léphetünk tovább.

new-exchangecertificate –generaterequest –domainame owa.doamin.hu, srvxch1.domain.hu, webmail.domain.hu, srvxch1, webmail 
–includeautodiscover > certreq.req

Sajnos a –path c:\certreq.req kapcsoló már nem létezik, így a legegyszerűbb, ha a kapott eredményt átirányítjuk egy fájlba.
 

2. Kulcs generálása

A Certificate szerveren a szükséges kulcsot az elkészített igényléssel a következő képpen hozhatjuk létre:

1. Belépés a Certificate Server-re
   
2. Kulcsigénylés kiválasztása
   
3. Kiterjesztett kulcsigénylés kiválasztása
   
4. Igénylés adatainak megadása
   
5. Elkészült kulcs letöltése
   

A létrehozott kulcsot én magam .p7b formátumba mentettem el.
 

3. Kulcs betöltése az Exchange szerverre

A létrehozott kulcsot még be kell töltenünk az Exchange szerver megfelelő tárolójába, a következő utasítással:

import-exchangecertificate –filedata ([Byte[]]$(get-content –path C:\certnew.p7b –encoding byte –readcount 0))

Sajnos itt is a bonyolultabb megoldás áll rendelkezésünkre a fájl tartalmának beolvasására, de a súgó segít a pontos szintaktikában!
 

Kulcs használatának beállítása

Miután a kulcsot betöltöttük “már csak” be kell állítani, hogy a szerverünk ezt használja az általunk kért funkciókhoz. Ennek menete a következő:

1. Elérhető kulcsok listázása, és a Thumbprint meghatározása
   

   [PS] C:\Windows\system32>Get-ExchangeCertificate

   Thumbprint                              Services Subject

   ———-                              ——– ——-

   D350FA4079F7707DF1F03294AE37A046B9E2FED8 IP….  CN=owa.domain.hu

   6CFEB76CB02E4515F52E4D03E7621882BED59163 ……  CN=srvxch1.domain.hu

   6D580B3EDBBFA408B86F713FE93EB5D61C3CDDD8 ……  CN=SRVXCH1.domain.hu

   29FAB7D0FB92673D1A9245717F76548D4B82FBEE ……  CN=SRVXCH1.domain.hu

   7E4914F1EE5050C462D4CC2916E03BBF9212FAC2 IP.WS.  CN=SRVXCH1

   Most már láthatjuk az újonnan betöltött kulcsunkat is, aminek a továbbiakban szükségünk lesz a Thumbprint kódjára a továbbiakban.

2. Kulcs használatának megadása
   

   [PS] C:\Windows\system32>Enable-ExchangeCertificate D350FA4079F7707DF1F03294AE37A046B9E2FED8 -Services imap, pop, iis

   Vegyük észre, annak meghatározása, hogy a kulcsot mire kell használnia a szervernek a –Services kapcsoló mögött megadott paraméterektől függ.

3. Beállítások ellenőrzése – összes kulcs listázása
   

   [PS] C:\Windows\system32>Get-ExchangeCertificate

   Thumbprint                              Services Subject

   ———-                              ——– ——-

   D350FA4079F7707DF1F03294AE37A046B9E2FED8 IP.WS.  CN=owa.domain.hu

   6CFEB76CB02E4515F52E4D03E7621882BED59163 ……  CN=srvxch1.domain.hu

   6D580B3EDBBFA408B86F713FE93EB5D61C3CDDD8 ……  CN=SRVXCH1.domain.hu

   29FAB7D0FB92673D1A9245717F76548D4B82FBEE ……  CN=SRVXCH1.domain.hu

   7E4914F1EE5050C462D4CC2916E03BBF9212FAC2 IP..S.  CN=SRVXCH1

4. Beállítások ellenőrzése – egy kulcs listázása
   

   [PS] C:\Windows\system32>(Get-ExchangeCertificate)[0] | fl

   AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessR

   ule, System.Security.AccessControl.CryptoKeyAccessRule}

   CertificateDomains : {owa.domain.hu, webmail.domain.hu, srvxch1, webmail, autodiscover.domain.hu}

   HasPrivateKey : True

   IsSelfSigned : False

   Issuer : CN=Domain Enterprise Root CA, DC=domain, DC=hu

   NotAfter : 2012.01.02. 16:37:01

   NotBefore : 2010.01.02. 16:37:01

   PublicKeySize : 2048

   RootCAType : Enterprise

   SerialNumber : 1501A128000000000009

   Services : IMAP, POP, IIS, SMTP

   Status : Valid

   Subject : CN=owa.domain.hu

   Thumbprint : D350FA4079F7707DF1F03294AE37A046B9E2FED8

A Microsoft sokszor segített már nekem ezen kérdések eldöntésében, így amikor az Exchange 2007 elé kerültem akkor is megoldotta a godius-i csomót, CSAK 64 bite-en támogatja az alkalmazást. Kis ideje megy már ez így előre, míg ma egy egyszerű dolgot kellett volna megoldani.

A kért feladat:
A megszűnt ExMerge.exe helyett oldjam meg valahogy, hogy rendszeres időközönként, automatikusan jöjjenek létre a felhasználók levelesládáinak PST fájlai (egy postaláda egy PST).

Megoldás:
Használjuk erre a export-mailbox utasítást az alábbiak szerint:

Export-Mailbox -Identity tamas.rigo@test.local -PSTFolderPath e:\rigo.pst

Ez gyorsan leprüntyögtem a szerveren, és ekkor jött a feketeleves egy szép hibaüzenet formájában:

Executing Command: ‘export-mailbox -Identity tamas.rigo@test.local -PSTFolderPath e:\rigo.pst’
[ERROR] You are running on a 64-bit computer. To export to or import from a .pst file, you must be running a 32-bit computer that has Outlook 2003 SP2 or later installed.

Értem én, elrontottam anno hogy átmentem 64 bitre, és azt is, hogy lökött vagyok, ezen igényt már nem illik 64 bites világban kérni. De mit csináljak ha ezt kérik… Most állhatok neki pluszban telepítgetni mindent 32 bitre, ja és ez egy plusz gép…