Coda di Exchange & R: Automatizzare e consolidare
Innumerevoli soluzioni alternative per i problemi di automazione, condivisione di cassette postali e consolidamento in Exchange.
Henrik Walther
Con contributore ospite Georg Hinterhofer
Resilienza del sito nei connettori di invio
D. Siamo nel processo di distribuzione di Exchange 2010 su più siti e impostazione per la ridondanza. Durante la pianificazione per la consegna della posta in uscita via smart host, vogliamo ottenere la ridondanza automatico nel caso in cui il sito principale va giù. Vorremmo che mantenere il traffico nel sito primario quando tutto va bene. Come possiamo noi realizzare questo?
**R.**È possibile aggiungere facilmente che più smart host in un connettore di invio e scambio sarà solo round robin attraverso di loro. Tuttavia, questo risolve solo un requisito: ridondanza tra i siti. Il traffico sarà ancora uniformemente distribuito anche quando tutti i siti sono su, in tal modo masterizzazione inutile della larghezza di banda tra i siti.
In questo caso, il connettore di invio è configurato con entrambi gateway di posta primari e secondari elencati come smart host. Exchange utilizzerà quelli in un ordine alternativo a consegnare la posta in uscita.
Per risolvere questo problema, è necessario applicare un trucco nifty insegnato presso Microsoft Certified Master formazione. Esso si basa sul fatto che la casella smart host in cambio la (versioni 2003, 2007 e 2010) non possono assumere solo i record o IP risolto affronta, ma deve anche tener record Mail Exchanger (MX) poco conosciuto. È possibile, tuttavia, assegnare priorità ai record MX.
Prima di tutto, verificare di che disporre di record DNS A per il gateway di posta sul posto. Successivamente, venire con un nome casuale per record MX presto creato nel DNS. In questo esempio, ho scelto di allsmarthosts.forest1.local. Creare il record MX richiesto nel DNS.
Con semplici basati su MX di routing, Exchange utilizzerà il record MX con priorità più alta, fino a quando è disponibile. Ora l'unica cosa a sinistra per fare è di riconfigurare il connettore di invio a leggere allsmarthosts.forest1.local come SmartHost solo Exchange.
Così facendo, Exchange utilizzerà primary.forest1.local per la posta in uscita, fintanto che essa è disponibile. Una volta che va giù o diventa irraggiungibile, Exchange inizierà utilizzando secondary.forest1.local come SmartHost. Ecco che cosa può fare per voi un piccolo inganno DNS.
Condivisione tra organizzazioni
D. Abbiamo recentemente acquisito una società che esegue Exchange 2010. Mentre il piano è quello di consolidare entrambi gli ambienti, abbiamo bisogno di stabilire immediatamente il calendario (non solo Free/Busy) condivisione tra le due organizzazioni. Sembra esserci poche informazioni là fuori. Potete condividere alcuni dettagli sul calendario di 1:1 come condivisione di opere e che cosa abbiamo bisogno di configurare per questo?
**R.**Questa funzionalità è stata sviluppata per 365 Office facilitare la coesistenza del locale. È possibile utilizzare per questo scenario pure. Entrambe le organizzazioni devono essere in esecuzione Exchange 2010. I client possono essere 2010 Outlook Web Access (OWA) o Outlook 2010.
In questo caso, il client di condivisione del calendario possibile specificare la quantità di informazioni (solo Free/Busy, Free/Busy più posizione, disponibilità con tutti i dettagli) a condividere. Quindi, come funziona? Tecnicamente, il proprio server di cassette postali creerà una copia o cache del calendario condiviso e mostrarlo a voi in Outlook o OWA. Questo è uno dei principali ostacoli blocchi. I server di cassette postali devono essere in grado di raggiungere Internet, come sono quelli eseguendo una query per gli elementi del calendario condiviso.
Quando si guarda il calendario condiviso in MFCMAPI, sembra molto simile a una personalizzata. L'eccezione è che esso è contrassegnato come di sola lettura. Si possono vedere tutti gli articoli dal calendario condiviso, come essi stanno davvero conservati nella propria cassetta postale.
Per impostare questo, è necessario configurare entrambe le organizzazioni per federarsi con la Microsoft Federation Gateway (MFG). Inoltre sarà necessario garantire che se un'organizzazione è ancora in esecuzione la versione RTM di Exchange, è necessario per almeno l'aggiornamento prima il service pack così ti ha colpito la stessa istanza della MFG. Non hai bisogno di relazioni organizzative in quel caso. (Avrebbe bisogno di quelli per la condivisione di disponibilità, ma si vorrà ottenere calendario condivisione in questo caso).
Di federare l'organizzazione con il MFG, basta seguire la procedura descritta qui. Sarà necessario pubblicare ulteriori record TXT DNS per comprovare la titolarità del dominio. Fatelo per entrambi i siti che si desidera federare e aggiungere domini appropriati. Inoltre, sarà necessario impostare le politiche di condivisione su entrambi i lati per consentire la condivisione con dettagli calendario.
Avviso i criteri predefiniti già consente agli utenti di condividere calendar Free/Busy info con il mondo intero (indicato dalla * dominio). Si desidera avere il calendario completo di condivisione con il partner, quindi è necessario impostare correttamente il quadrante di condivisione e aggiungere i domini dell'organizzazione che si desidera essere in grado di condividere con. Ancora una volta, è necessario fare questo in entrambi i siti.
Le politiche di condivisione efficacemente consentono di controllare quali utenti possono condividere i loro calendari e con chi. Questa condivisione non è limitata agli elementi del calendario. È possibile condividere i vostri contatti pure.
Prima di condividere il calendario. Il destinatario può quindi scegliere di aggiungere il calendario condiviso. Calendario apparirà presto con gli elementi condivisi.
Se avete bisogno risolvere i problemi di questo, un buon punto di partenza è a guardare l'URL reale. Questo viene archiviato nella cassetta postale del destinatario. È possibile recuperare con MFCMAPI. Assicurarsi che l'URL sia raggiungibile dal vostro server cassette postali locali.
Agenti di estensione cmdlet
D. Per ogni nuova cassetta postale che creiamo, vogliamo rendere inabile ActiveSync per impostazione predefinita. Accesso deve solo essere disponibile su richiesta. Tuttavia, quando si crea una nuova cassetta postale con il cmdlet New-Mailbox, noi non abbiamo la possibilità di disattivare ActiveSync al momento della creazione. Abbiamo bisogno di eseguire un –ActiveSyncEnabled Set-CASMailbox:$ false manualmente dopo la creazione. Persone a volte dimentica questo passaggio e quindi lasciare ActiveSync accesso abilitato per le persone che non dovrebbero avere accesso. Sapete di un modo per modificare queste impostazioni predefinite a livello globale, o c'è qualche altro modo facile intorno ad esso?
**R.**Questa questione si presenta molto spesso. Purtroppo, la risposta breve è no. Non non c'è alcun modo per modificare tali impostazioni predefinite (ad esempio Web Access attivata per impostazione predefinita, ActiveSync attivata per impostazione predefinita, tenere premuto contenzioso disabilitato e così via). Exchange configurerà sempre quelli ai suoi gusti hardcoded.
Fortunatamente, c'è un modo per aggirare questa limitazione — con agenti di estensione cmdlet. Che cosa fa un agente di estensione cmdlet (denominato anche a volte come agente di script) è ascoltare qualsiasi comando di Exchange essere licenziato. Se programmato a farlo, sarà eseguire qualsiasi comando dato in seguito o modificare i dati nel cmdlet effettivo essere licenziato.
Ecco un esempio che soddisfa la tua domanda:
New-Mailbox -Name "Georg Hinterhofer" -Database DB1 -UserPrincipalName hiho22@hihosoft.local –Password $p.password
Questo crea un utente con tutte le impostazioni predefinite sul posto. L'agente di estensione cmdlet rileva che ha eseguito il cmdlet New-Mailbox e rotazioni automaticamente su un secondo cmdlet (quello che non è visibile a voi). Esso viene eseguito Set-CASMailbox – Identity hiho22 –ActiveSyncEnabled:$ false, la configurazione delle impostazioni di tutte le vostre esigenze.
Così come ci arriva l'agente attivo e funzionante? Prima di tutto, identificare quale azione si desidera impostare come il grilletto e l'azione da eseguire quando il trigger viene generato. In questo caso, è facile. Ogni volta che qualcuno viene eseguito il cmdlet New-Mailbox, si desidera avviare il cmdlet Set-CASMailbox per disabilitare ActiveSync.
Ora si può andare e fare la codifica effettivi. Cercare un file denominato scriptingagentconfig.xml.sample in %ExchangeInstallPath%\bin\CmdletExtensionAgents e copialo. Rinominare la copia di leggere solo scriptingagentconfig.xml e aprirlo con il vostro editor preferito. Per questo esempio, modificare il contenuto del file per essere simile a questo:
<?xml version="1.0" encoding="utf-8" ?> <Configuration version="1.0"> <Feature Name="DisableEASonNewlyCreatedMailboxes" Cmdlets="new-mailbox"> <ApiCall Name="OnComplete"> if ($succeeded) { $dc = (Get-ADServerSettings).DefaultPreferredDomaincontrollers $user = $provisioninghandler.UserSpecifiedParameters["UserPrincipalName"] set-casmailbox $user -ActiveSyncEnabled:$false -DomainController $dc.item(0) } </ApiCall> </Feature> </Configuration>
Salvare il file modificato. Se avete più di un server Exchange, inoltre è necessario utilizzare la copia modificata del file per ognuno di tali server. Da notare anche come Get-ADServerSettings determina il controller di dominio preferito per evitare eventuali errori relativi alla latenza di replica di Active Directory. È possibile rimuovere questa opzione se si dispone solo di un controller di dominio nel proprio ambiente.
Infine, sarà necessario abilitare l'agente di Scripting. Questo è un'impostazione di tutta l'organizzazione, quindi è necessario eseguire questo solo una volta, non una volta per ogni server:
Enable-CmdletExtensionAgent "Scripting Agent"
Verificare l'esito e il gioco è fatto. Ora, eseguire tutti preferito cmdlet New-Mailbox e guarda come ActiveSync viene automaticamente disattivato.
.jpg)
.jpg)
Henrik Walther è un Microsoft Certified Master: Exchange 2007 ed Exchange MVP con più di 16 anni di esperienza nel settore IT. Lavora come technology architect per Microsoft gold partner in Danimarca e come un technical writer per Biblioso Corp. (una società statunitense specializzata in gestione servizi di localizzazione e documentazione). È anche un fornitore contrattato lavorando su vari team di prodotto (comprese le squadre di Exchange e Lync) di Microsoft.
Georg Hinterhofer è un Microsoft Certified Master: Exchange 2010. Egli lavora come ingegnere senior campo premier, concentrandosi su unicamente su Microsoft Exchange. Egli è basato in Austria, nei pressi di Vienna.