Filtra gli utenti importati con dirsync in Office 365

16 marzo 2012

Dirsync è lo strumento di Office 365  che permette di importare gli utenti presenti in Active Directory nel sistema cloud in modo automatico.
Una volta attivato il processo di sincronizzazione importerà tutti gli oggetti compresi quelli che non si vorrebbe importare. A tal proposito, anche se sconsigliato da Microsoft, è possibile fare un pò di “pulizia” applicando dei filtri agli oggetti da importare.

Per esempio una delle richieste più frequenti è quella di non importare in Office 365 gli utenti che in Active Directory sono disabilitati. Per fare è sufficiente applicare il seguente filtro alla categoria utenti:

userAccountControl = 0×202
userAccountControl = 0×10202

E’ necessario settare entrambi i valori per escludere gli account disabilitati che hanno il flag password “never expire” e per quelli disabilitati senza tale opzione fleggata.

Altro esempio potrebbe essere quello di importare solo gli utenti con il suffissio UPN corretto (mi è capitato che il cliente non volesse cambiare l’UPN agli utenti di servizio o “particolari”).

In questo caso è sufficiente impostare il filtro come nella figura qui sotto.

Questi ed altri filtri possono essere combinati insieme, ma è sembre bene usare tale strumento con attenzione e parsimonia soprattutto quando in Office 365 sono già state assegnate licenze e attivati contenuti.

BPOS – Informazioni sulla scadenza delle password

14 marzo 2012

In questo mesi, Microsoft sta effettuando la migrazione dei suoi servizi cloud dalla piattaforma BPOS a quella basata su Office 365.
Uno dei diversi requisiti necessari per garantire l’accesso agli utenti alle proprie mailbox dopo la migrazione è quello di cambiare la password entro 30 giorni dalla data di migrazione. Una informazione utile durante la fase di preparazione alla transizione è quella di conoscere quanti utenti non hanno cambiato la password nel periodo corretto.

Durante le migrazioni che ho seguito ho trovato due metodi per ricavare questa (e altre) utile informazione.

Metodo 1

Creare un file csv con l’elenco degli utenti nel seguente formato:

identity
user1@dominio.com
user2@dominio.com
Collegarsi a BPOS tramite la relativa powershell con una utenza amministrativa ed eseguire il seguente comando:
Import-csv %path%\fileutenti.csv | get-msonlineuser | ft identity,PasswordExpirationDate,PasswordLastSetDate
Il risultato dell’esportazione sarà un file di questo tipo:
Identity PasswordExpirationDate PasswordLastSetDate
user1@dominio.com 04/10/2011 15:43 06/07/2011 15:43
user2@dominio.com 07/11/2011 09:55 09/08/2011 09:55
Metodo 2
Il secondo metodo è quello di utilizzare il tool indicato nel seguente link http://www.messageops.com/bpos-reporter-now-available
A presto.

The Certificate Status could not be determined because the revocation check failed

6 febbraio 2012

Tra i vari progetti in cui sono stato coninvolto negli ultimi tempi c’è una migrazione da Exchange 2007 a Exchange 2010 di una organizzazione di circa 1500 mailbox distribuiti su Milano e Roma.

Durante questa migrazione, sul server CAS di uno dei due siti si è presentato l’errore sul certificato di terze parti che dà il titolo a questo post:

The Certificate Status could not be determined because the revocation check failed

 

 

 

Durante il troubleshooting ho provato a ri-esportare e reimportare nuovamente il certificato con Powershell per evitare possibili problemi riguardanti l’integrità del file .pfx.

Successivamente ho verificato quanto indicato in questo link del technet Microsoft., ma ciò che ci è stato davvero utile nella risoluzione del problema è stato “banalmente” il tool messo a disposizione da Digicert qui. Il tool consiste in un semplice eseguibile da copiare sul server con i problemi che si stanno analizzando e non necessita di nessun tipo di installazione.

Una volta eseguito il tool il risultato è stato abbastanza chiaro:

 

 

In effetti il tutto si è risolto modificando le regole del proxy del sito con il problema.

Domini con DNS etichetta Singola

6 febbraio 2012

Nelle ultime settimane mi sto occupando di alcuni clienti che stanno integrando i domini Active Directory delle società che hanno acquisito nel mondo all’interno della proprio foresta. In più di una occasione però, durante gli assessments preliminari, mi sono imbattuto in domini che presentavano un DNS ad etichetta singola. Per intenderci:

Dominio classico: dominio.com

Etichetta Singola (o Single Label): dominio

Questo tipo eventualità è definitivamente scomparsa dalla versione 2008 in poi: la procedura di promote (dcpromo) del primo DC 2008 e superiori non permette infatti di inserire un dominio ad etichetta singola nel caso si tratti di una nuova foresta.

I domini con DNS ad etichetta singola creano grossi problemi in caso si decida di effettuare, come nel mio caso, una migrazione dei sistemi Microsoft tramite ADMT. Infatti, se non si configurano correttamente i computer membri del dominio in modo corretto questi quasi sicuramente non si registreranno nel DNS: ciò significa che non si potrà effettuare lo step di security translation e switch al dominio target.

Fortunatamente questo è un caso ampliamente documentato nella KB di Microsoft a questo link.

Nel mio caso è stato più conveniente implemetare una policy come indicato nel link precedente visto il numero di client impattati (oltre 200); googolando qua e là ho letto anche della possibilità di settare tali parametri con degli script con l’accorgimento di disabilitare eventuali firewall sulle macchine.

Operazione sulla cassetta postale “User” non riuscita poiché esterna all’ambito di scrittura dell’utente corrente

16 dicembre 2011

Durante lo scorso week-end ho supportato un cliente nella migrazione da un sistema di posta MAPI (Critical Path) al servizio di posta basato su Microsoft Office 365 (O365).

Lo scenario era composto da una foresta Active Directory con diversi child domain (circa uno per nazione) i cui utenti si sincronizzano su O365 tramite un server dirsync.
Come ho già detto prima il sistema di posta oggetto di migrazione basato su Critical Path.

La procedura di migrazione è stata la seguente:

1. Pulizia di Active Directory e modifica del nome di accesso per gli utenti Active Directory (UPN) secondo la naming convention nome.cognome@nomeazienda.com (nomeazienda.com è stato definito tramite la configurazione\procedura di aggiunta di un suffisso upn alternativo).

2. Su O365 è stato verificato che l’utente sia stato correttamente sincronizzato e, se necessario, è stato impostato il nome di accesso a O365 da nome.cognome@nomeazienda.onmicrosoft.com a nome.cognome@nomeazienda.com

3. Agli utenti è stata assegnata una nuova password tramite script powershell

4. Assegnazione del piano di licenza tramite script powershell

5. Durante la migrazione è capitato che alcuni utenti necessitavano di modifiche e\o aggiunte agli indirizzi mail alternativi ma durante l’esecuzione di tali modifiche tramite portale O365 si verifica il seguente errore:

Operazione sulla cassetta postale “Nome Cognome” non riuscita poiché esterna all’ambito di scrittura dell’utente corrente. L’azione ‘Set-Mailbox’, ‘EmailAddresses’, non può essere eseguita sull’oggetto ‘Nome Cognome’ in quanto tale oggetto viene sincronizzato dall’organizzazione on-premises. Tale azione deve essere eseguita sull’oggetto nell’organizzazione on-premises.

Questo errore si presenta in quanto l’oggetto è di “proprietà”  dell’active directory on-premises e solo in quell’ambito è possibile apportare modifiche all’oggetto.

Concretamente le operazioni da compiere per aggirare il problema sono le seguenti:

  1. Aprire lo strumento di amministrazione Users and Computers da un server 2008
  2. Impostare la visualizzazzione avanzata
  3. Selezionare l’utente (non dalla maschera trova dello snapin) e con il tasto destro aprire le proprietà
  4. Selezionare il tab “Attribute editor”
  5. Selezionare la voce proxy address
  6. Settare gli indirizzi anticipati da smtp (Maiuscolo per l’inirizzo principale)

E’ possibile effettuare queste operazioni anche tramite adsiedit.


Copy Protected by Chetan's WP-CopyProtect.