OCS 2007 - Al restart del server i servizi OCS non si avviano

In questi giorni ho gestito un caso relativo ai problemi di avvio dei servizi su un environment Office Communication Server 2007 R2.

Il cliente ha lamentato il problema dopo la rimozione manuale di un vecchio pool OCS R1 e il conseguente riavvio dei server. Dopo tale riavvio tutti i server OCS, appartenenti a differenti Pool, e il server di monitoring non riuscivano ad avviare i servizi OCS.

L’errore generato e visibile su tutti i server OCS era il seguente.

Log Name: Office Communications Server

Source: OCS WMI Consumer

Date: 10/11/2011 8.30.45

Event ID: 20482

Task Category: (1002)

Level: Error

Keywords: Classic

User: N/A

Computer: server.dominio.local

Description:

Server could not retrieve its initial configuration for a class from the WMI Provider.

Class: MSFT_SIPESTrustedServerSetting

Cause: This can occur if the connection to Active Directory or SQL back-end database is down or if permissions to the service account are altered. Retrieval can also fail if an invalid entry is entered in the class using the UI or WMI or if corruption occurs in local WMI repository.

Resolution:

Make sure the account the service is running under has proper privileges and that connection to Active Directory or SQL back-end database is functional. Verify an identical entry does not exist as a direct federation partner or an IM service provider.

Dopo questo errore erano presenti molti altri errori relativi al mancato avvio degli altri servizi.

Il cliente contestualmente a queste operazioni aveva installato le patch di sicurezza per Windows Server 2008.
Come prima cosa abbiamo verificato che il problema non fosse causato dall’aggiornamento vulnerabilità di CryptoAPI e controllato la connettività con il server SQL.

MS09-056: Possibili rischi di spoofing a causa di una vulnerabilità di CryptoAPIhttp://support.microsoft.com/kb/974571 .

Una volta smarcati questi due aspetti abbiamo proceduto a catturare una trace LCSWMI usando il Logging Tool presente un un server FE di uno dei pool OCS R2.

Dal seguente log si evinceva il seguente errore.

Estratto traccia LCSWMI.etl

1,0x0b84,0x0ba0,2011/11/24-07:37:04.641,TL_INFO,lcswmi,LcStoreAd_cpp5418,InitiateSearch(),"Initiated search: (&(objectCategory=msRTCSIP-TrustedServer))"

0,0x02e4,0x0870,2011/11/24-07:37:04.641,,coredll,wbemname_cpp11004,CWbemNamespace::GetObjectW(),"CALL CWbemNamespace::GetObject   BSTR ObjectPath = MSFT_SIPESTrustedServerSetting   long lFlags = 0   IWbemClassObject ** pObj = 0000000002E85240"

0,0x0b84,0x0ba0,2011/11/24-07:37:04.642,TL_INFO,lcswmi,LcStoreAd_cpp7726,SaveAdValueToWmiInstance(),"InstanceID: '{OBJ ID}'"

1,0x0b84,0x0ba0,2011/11/24-07:37:04.642,TL_WARN,adhelper,AdSearch_cpp329,ADSearch::GetAttribute(),"m_piDirSearch->GetColumn() failed!  hr = HRESULT=80005010"

1,0x0b84,0x0ba0,2011/11/24-07:37:04.642,TL_ERROR,adhelper,AdWmiHelper_cpp491,GetAttribute(),"pSearch->GetAttribute() failed!  hr = HRESULT=80005010"

1,0x0b84,0x0ba0,2011/11/24-07:37:04.642,TL_INFO,lcswmi,LcStoreAd_cpp9057,SaveDefaultAdValueToWmiInstance(),"attribute(msRTCSIP-TrustedServerFQDN) is not set and there is no default value for it."

0,0x0b84,0x0ba0,2011/11/24-07:37:04.642,TL_INFO,lcswmi,LcStoreAd_cpp7748,SaveAdValueToWmiInstance(),"Version: '3'"

Ho quindi chiesto un Export degli oggetti RTC presenti in AD utilizzando lo strumenti ldifde e eseguendo i i seguenti comandi:

Configuration Partition:
ldifde -d CN="RTC Service",CN=Services,CN=Configuration,DC=domainname,DC=com -p subtree -f c:\RTCUserConfiguration_output.txt

System Partittion:
ldifde -d CN="RTC Service",CN=Microsoft,CN=System,DC=<domain>,DC=<net> -p subtree -f c:\ RTCUsersystem_output.txt

Con questi commandi ho potuto verificare che nel System container non ci fossero oggetti e, nello stesso tempo, avere un export degli oggetti RTC nel configuration container.
Dall’analisi di questi oggetti ho trovato la seguente anomalia.

dn: CN={Object CN},CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=dominio,DC=local

changetype: add

objectClass: top

objectClass: container

objectClass: msRTCSIP-TrustedServer

cn: { Object CN }

distinguishedName:

CN={ Object CN },CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=dominio,DC=local

instanceType: 4

whenCreated: 20110907144316.0Z

whenChanged: 20111104090941.0Z

uSNCreated: 753593

uSNChanged: 1997841

name: { Object CN }

objectGUID:: Object GUID==

objectCategory:

CN=ms-RTC-SIP-TrustedServer,CN=Schema,CN=Configuration,DC=dominio,DC=local

dSCorePropagationData: 20110908092438.0Z

dSCorePropagationData: 20110908092117.0Z

dSCorePropagationData: 20110908082004.0Z

dSCorePropagationData: 16010101181633.0Z

msRTCSIP-TrustedServerVersion: 3

dn: CN={ Object CN 2},CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=dominio,DC=local

changetype: add

objectClass: top

objectClass: container

objectClass: msRTCSIP-TrustedServer

cn: { Object CN 2}

distinguishedName:

CN={ Object CN 2 },CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=dominio,DC=local

instanceType: 4

whenCreated: 20110908124334.0Z

whenChanged: 20110908124334.0Z

uSNCreated: 877038

uSNChanged: 877038

name: { Object CN 2}

objectGUID:: Object GUID==

objectCategory:

CN=ms-RTC-SIP-TrustedServer,CN=Schema,CN=Configuration,DC=dominio,DC=local

dSCorePropagationData: 16010101000000.0Z

msRTCSIP-TrustedServerVersion: 4

msRTCSIP-TrustedServerFQDN: ocspool.dominio.local

Come si può vedere il primo oggetto non contiene l’attributo msRTCSIP-TrustedServerFQDN che, invece, è presente nell’altro oggetto.
Questo ci ricollega all’errore trovato nella traccia catturata server-side (attribute(msRTCSIP-TrustedServerFQDN) is not set and there is no default value for it.)

Un’altra importante informazione che si evince da questo log è la versione dell’oggetto.
E’ possibile verificate tale informazioni dall’attributo msRTCSIP-TrustedServerVersion.

- Version: '3'" (Dato presente nella traccia LCSWMI) o msRTCSIP-TrustedServerVersion: 3 == OCS R1
- Version: '4'" (Dato presente nella traccia LCSWMI) o msRTCSIP-TrustedServerVersion: 4 == OCS R2
- Version: '5'" (Dato presente nella traccia LCSWMI) o msRTCSIP-TrustedServerVersion: 5 == LYNC

Avendo rimosso manualmente l’ultimo Pool/Server OCS R1 ho potuto individuare la causa del problema. Evidentemente non sono stati eseguiti i corretti passaggi per la rimozione del Pool OCS R1.

Abbiamo quindi effettuato un Backup di AD e successivamente rimosso l’oggetto.
Dopo la cancellazione dell’oggetto in AD il problema si è risolto.

La query WMI relativa alle classi MSFT_SIPESTrustedServerSetting non aveva valore per l’attributo msRTCSIP-TrustedServerFQDN per una specifica instanza e ciò comportava il problema di avvio dei servizi.

Questo articolo descrive uno specifico problema, ma può essere utile come linea guida o più generalmente come approccio per la fase di troubleshooting di problematiche simili.

Buona giornata

Stefano Ceruti
Support Engineer
Microsoft Enterprise Exchange Support