R: e coda di Exchange Gestione della migrazione
La gestione del processo di migrazione è sempre un problema. Esistono diversi modi per ottimizzare e controllare meglio il processo.
Henrik Walther
Schema di aggiornamento
D. Stiamo utilizzando Microsoft Exchange Server 2010 SP1 come la nostra infrastruttura di messaggistica. Stiamo progettando di eseguire l'aggiornamento a Exchange Server 2010 SP2. Vogliamo farlo il più presto possibile, perché vogliamo usare le nuove politiche di libro di indirizzo (SOA).
Mentre ci prepariamo per l'aggiornamento a Exchange 2010 SP2, noi non sono sicuri se dobbiamo preparare Active Directory utilizzando "Setup /PrepareAD." È abbastanza per estendere l'utilizzo dello schema e "Setup /PrepareSchema?" Abbiamo visto "versioni dello Schema di Exchange – domande comuni & Le risposte"su TechNet wiki, ma che non dice nulla circa l'obbligo di preparare Active Directory, solo lo schema.
Nel nostro ambiente di laboratorio, abbiamo solo corse "Setup /PrepareSchema" e sono stati in grado di aggiornare i server Exchange 2010 a SP2 senza problemi. Si potrebbe far luce su questo?
**R.**Prima di aggiornare i server Exchange 2010 a SP2, è necessario estendere lo schema utilizzando "Setup /PrepareSchema." È inoltre necessario preparare Active Directory utilizzando "Setup /PrepareAD." Per le distribuzioni di piccole, si potrebbe avere l'installazione guidata di preparare automaticamente il vostro gruppo per l'aggiornamento. Si può fare questo se l'account effettuato detiene le autorizzazioni necessarie.
In ambienti aziendali di grandi dimensioni, è una buona idea per preparare lo schema e Active Directory in fasi distinte. I clienti aziendali più grandi richiedono questo approccio, che di solito hanno un Active Directory dedicato per effettuare queste operazioni di preparazione.
Sembra che erano in grado di aggiornare i server Exchange 2010 in laboratorio senza correre "Setup /PrepareAD" perché si erano effettuato con un account con le autorizzazioni appropriate.
Controllo della migrazione
D. Siamo un grande fornitore di hosting Exchange, e abbiamo intenzione di migrare a Exchange 2010 in esecuzione in modalità non hosted, usando un pannello di controllo di terze parti per la logica di provisioning e multi-tenancy.
Perché che usando un pannello di controllo di terze parti, auguriamo disabilitare l'accesso per l'impostazione di "Gestire la mia organizzazione" per gli amministratori di Exchange l'accesso al pannello di controllo Exchange (ECP). Non vogliamo disabilitarne l'accesso ECP in generale, solo la funzionalità di "Gestire la mia organizzazione" (vedere Figura 1). Sapere se questo è possibile?
.jpg)
Figura 1 si può disabilitare l'accesso ad alcune funzioni.
**R.**Non poteva farlo prima di Exchange 2010 SP2, a meno che non in esecuzione in modalità hosted Exchange 2010. Che non è di dire che si dovrebbe aver distribuito Exchange 2010 in modalità ospitati. Noi consigliamo in realtà contro facendo questo e invece preferiscono lasciare che una soluzione di pannello di controllo di terze parti fanno tutti il provisioning e multi-tenancy, come hai fatto.
Così, con Exchange 2010 SP1 in esecuzione in modalità hosted, una delle nostre raccomandazioni era per disabilitare l'accesso all'opzione "Gestire la mia organizzazione" all'interno di ECP. È possibile farlo utilizzando una chiave del Registro di sistema, come spiegato nel documentazione di Exchange 2010 Hosting. Si crea una chiave DWORD denominata "OMECPDisabled" sotto "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\ExchangeServer\v14". Nota che non è necessario impostare un valore per questa chiave (vedere Figura 2).
.jpg)
Figura 2 è relativamente semplice per abilitare o disabilitare l'accesso con le chiavi del Registro di sistema.
Dopo la creazione di tale chiave, vorrei vedere ciò che viene mostrato Figura 3 quando si accede a ECP. Non esiste più un menu a discesa "Gestire Myself" e non avete nessun accesso effettuare qualsiasi amministrazione sul livello dell'organizzazione mediante ECP — missione compiuta.
.jpg)
Figura 3 dopo aver fatto questa modifica, sei bloccato di funzioni amministrative.
Notare che questa risposta ha cominciato con "prima di Exchange 2010 SP2"? La chiave del Registro di sistema non è supportata con Exchange 2010 in modalità non hosted quando si esegue Exchange 2010 SP1 o versioni precedenti. Ecco la buona notizia, anche se: con Exchange 2010 SP2, è possibile utilizzare la stessa chiave per compiere lo stesso obiettivo in ambienti di modalità non hosted Exchange 2010.
Qualsiasi porta in una migrazione
D. Attualmente stiamo distribuendo e configurare l'ambiente Exchange 2010 a cui ci sarò migrare da Exchange 2003 quest'anno. E-mail è critica all'interno della nostra organizzazione, così naturalmente impiegherà un array Accesso Client e gruppi di disponibilità del Database (DAG). Per caricare il traffico client in arrivo di equilibrio tra il server Accesso Client nella matrice Client Access Service (CAS), useremo un bilanciamento del carico hardware. Abbiamo sentito che è una buona idea per configurare le porte di statica remote procedure call (RPC) sui server CAS in un tale scenario. Qual è la tua opinione?
**R.**La risposta breve è sì: Si dovrebbe considerare fortemente configurazione porte RPC statiche. Le ragioni sono molteplici.
In primo luogo, è sempre una buona idea per mantenere il vostro firewall/rete/sicurezza ragazzi felici. Non chiediamo loro di tenere aperti gli intervalli di IP. Invece, chiedere loro di aprire alcune porte singoli. Se si dispone di uno o più firewall in atto tra le subnet(s) del cliente e il carico server bilanciatore/Exchange 2010, è non configurare le porte RPC statiche sul vostro server CAS. Dovete chiedere loro di aprire una vasta gamma di porta RPC (più specificamente, la porta TCP 135 e l'intervallo di porte dinamiche 6005-59530).
Configurando porte RPC statiche, solo bisogno di chiedere tre porte: TCP/135 (mapping degli endpoint TCP), alla porta assegnata al CAS RPC ed il porto assegnato al servizio Exchange Address Book.
In secondo luogo, quando si utilizza un bilanciamento del carico hardware e non configuri porte RPC statiche, spesso vedrete un footprint di memoria più grande che se configurato porte RPC statiche. Inoltre, alcuni bilanciatori di carico non giocano bene con intervalli di porta dinamico in generale. Infine, è più facile da configurare una soluzione di monitoraggio per monitorare i tre porti invece di un intervallo di porte dinamiche.
Per informazioni su come configurare le porte RPC statiche, dare un'occhiata alla pagina wiki di TechNet, "configurazione statica porte RPC su un Exchange 2010 Client Access Server."
.jpg)
**Henrik Walther**è un Microsoft Certified Master: Exchange e MVP Exchange con più di 16 anni di esperienza nel settore IT. Egli lavora come technology architect per Microsoft partner in Danimarca e come un technical writer per Biblioso Corp., una società statunitense specializzata in servizi di localizzazione e documentazione gestita.Walther è anche un venditore contrattato, lavorando per le squadre di prodotto varie, tra cui le squadre di Exchange e Lync, presso Microsoft. E-mail lui al v-henwal@microsoft.com.