Supporto Tecnico Enterprise : Alessandro Pasero

OCS 2007 - Problema di integrazione con Outlook: Impossibile recuperare le informazioni del calendario

itentblg — Mon, 17 Aug 2009 02:00:00 GMT

Come sappiamo Office Communicator è altamente integrato con Outlook ed Exchange mettendo a disposizione una serie di feature come la presence, la conversation histroy, la missed-call history, ecc

Il Communicator ottiene inoltre da Outlook e/o da Exchange una serie di informazioni, tra cui quelle relative all’ Out of Office e al calendario, per poter aggiornare conseguentemente la presenza dell’utente. Le informazioni vengono ottenute sia via MAPI che tramite i Web Services di Exchange.

Una spiegazione di come funziona questo meccanismo è data sul blog ufficiale del team che si occupa dello sviluppo del Communicator:
Office Communicator Team Blog : Communicator and Exchange – Special considerations for deploying Communicator in an Exchange environment

PROBLEMA

Per un nuovo utente era stato preparato un nuovo account ed una macchina di lavoro che prevedeva Outlook 2003 e Office Communicator 2007; nell’infrastruttura il server era un Exchange 2003 EE.

All’avvio del Communicator, successivo all’avvio di Outlook, è stato notato il seguente messaggio di errore:

che sulla versione in lingua Inglese corrisponde a:

“Cannot retrieve your Outlook calendar information. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.”

Un messaggio di errore del Communicator che indicava l’impossibilità di scaricare le informazioni del calendario e che persisteva durante l’utilizzo del Communicator.

ANALISI

Come abbiamo detto sopra, il Communicator scarica le informazioni del calendario da Exchange, per i client Outlook 2007 con Exchange 2007 tramite gli Exchange Web Services oppure via MAPI.

Il tempo di polling del Communicator è modificabile via policy:

MapiPollInterval	Frequency of loading calendar data from MAPI.
WebServicePollInterval	Frequency of loading calendar data from the Web services provider.

Se l’utente non sta’ però pubblicando queste informazioni il Communicator non potrà aggiornare lo stato a sua volta, abbiamo quindi per prima cosa controllato se fossero state cambiate le impostazioni di default di Outlook:

Abbiamo poi verificato sul client Communicator che le impostazioni nel Personal Information Manager fossero settate su Outlook (in Tools -> Options):

Siccome risultava tutto configurato correttamente abbiamo abilitato i log del Communicator, da Tools –> Options -> General –> Logging

Dopo aver flaggato la voce: “Turn on logging in Communicator” e nessessario uscire e ri-loggarsi affinché le modifiche vengano accettate; verranno creati due file nella directory %userprofile%\Tracing: Communicator-uccapi-X.uccapilog e Communicator.etl.

Mentre il file .uccapilog è leggibile con Snooper, un tool del resource kit, ma anche semplicemente con il NotePad, il file ETL deve essere necessariamente mandato al supporto tecnico Microsoft per essere convertito in testo e interpretato.

La voce “Turn on Windows Event logging for Communicator” serve invece ad abilitare il Windows Event logging.

Maggiori informazioni sono reperibili sul blog ufficale di OCS: OCS Client Logging Capabilities (MOC)

Abbiamo quindi chiesto al cliente di abilitare i log, loggarsi nuovamente, aspettare che si riproducesse il problema e mandarci il file Communicator.etl.

Dal file etl risultava che il task incaricato del caricamento delle informazioni del calendario , restituiva il codice di errore 0x8004010F ovvero MAPI_E_NOT_FOUND.

SOLUZIONE

Abbiamo semplicemente inserito un evento nel calendario vuoto e l’errore è scomparso, non si tratta quindi di un vero problema, ma semplicemente del fatto che le informazioni non sono effettivamente presenti; il messaggio infatti non viene più riscontrato dopo che un appuntamento è stato creato almeno una volta.

Questo comportamento è presente solo con Outlook 2003 + Exchange 2003 di cui tra l’altro è ormai terminato il supporto mainstream:

come visto risolverlo è comunque molto semplice, in quanto al primo elemento inserito nel calendario l’errore lato Communicator sparice.

Rimando inoltre al seguente articolo di KB che descrive il motivo del possibile ritardo nell’aggiornare lo stato lato Communicator nella stessa configurazione: Communicator 2007 does not update the free/busy information as scheduled

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Presence unknown con utenti LCS 2005

itentblg — Mon, 10 Aug 2009 02:00:00 GMT

Nell’interazione tra Live Communications Server 2005 e Office Communications Server 2007 è capitato ad alcuni clienti di incappare in un problema legato alla “presence” degli utenti OCS; sostanzialmente gli utenti LCS2005 vedevano la presenza di quelli attestati su OCS sempre “Unknown” con relativo pallino color grigio.

Inoltre gli utenti LCS non riuscivano ad iniziare una sessione di IM con quelli OCS ma era possibile il contrario.

La prima cosa da fare per capire la causa di comportamenti simili è riprodurli abilitando i log sia sui client che sui server in modo da poter ricostruire ciascun passaggio.

Di seguito vediamo le azioni da svolgere.

Abilitazione Log

Su LCS 2005:
Trovate una descrizione su come abilitare i log in LCS 2005 SP1 nella Reference Guide da pag 37 in poi e reperibile qui:
Live Communications Server 2005 with SP1: All Technical Documents
Nel Tab logging abbiamo impostato il “Logging Level” a 4 per avere il maggior dettaglio possibile.
Su OCS 2007:
Con OCS è stato introdotto un tool di logging molto comodo: Replacement of Flat File Logging Functionality
Come descritto al link abbiamo abilitato il logging per il componente SIPStack.
Su MOC 2007:
Basta andare in ToolsàOptionsàGeneral e abilitare la voce “Turn on logging in Communicator”.
Le trace saranno disponibili nel folder %USERPROFILE%\Tracing con il nome: Communicator-uccapi-X.uccapilog
Per aprirlo è necessario il tool Snooper reperibile nel Resource Kit.
Su MOC 2005:
Si tratta di impostare le seguenti chiavi di registry:
HKCU\Software\Microsoft\Tracing\Communicator EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCAPI EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCIMSP EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\LCMSGSC EnableFileTracing=1
HKCU\Software\Microsoft\Tracing\lcmedia_rtp EnableFileTracing=1

Le trace saranno disponibili nel folder %USERPROFILE%\Tracing
How to enable diagnostic logging for Office Communicator and for Windows Messenger

Riprodurre il problema

Per riprodurre abbiamo semplicemente eseguito il login su un MOC 2005 che aveva nella sua lista di contatti alcuni utenti 2007 e constatato dopo qualche minuto che la presenza risultava sempre sconosciuta.

Ricordatevi di disabilitare i log dopo il test se non vi serve mantenerli attivi per ulteriori test.

ANALISI

Per iniziare l’analisi è certamente essenziale avere ben chiaro l’ambiente del cliente, personalmente cerco sempre di farmi uno schema della parte di infrastruttura che mi interessa, con gli indirizzi IP, i nomi macchina e tutto quello che possa tornarmi utile ai fini dell’analisi.

A tal proposito se voleste raccogliere i dati di una macchina in particolare, potete utilizzare l’"MPS Report" che è parte del Microsoft Product Support's Reporting Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyID=00ad0eac-720f-4441-9ef6-ea9f657b5c2f&DisplayLang=en

Il programma genera un file NomeMacchina_MPSReports.CAB salvato nella cartella: "C:\WINDOWS\MPSReports\PFE\Report\Cab" contenente numerosissime informazioni sullo stato del server e sulla relativa configurazione.

Dall’analisi dei dati raccolti avevamo notato il seguente errore:

$$begin_record

LogType: connection

Date: 2009/02/22 11:31:52

Severity: 1

Text: The connection matched by IP address had the wrong peer name

Peer-IP: 10.0.0.1:5061

Peer-Name: server_name.contoso.local

Transport: M-TLS

$$end_record

Effettivamente il mismatch c’era in quanto il “Peer Name” corrispondeva all’ FQDN del server fisico OCS, mentre l’indirizzo IP era quello del Pool.

Questo mismatch portava di conseguenza ad un 504 Server Time-Out alla richiesta di sottoscrizione iniziale:

$$begin_record

LogType: diagnostic

Date: 2009/02/22 11:31:52

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 949157e5a19d4d8b91a5541ecb7f2e1

SIP-CSeq: 1 SUBSCRIBE

Peer: 191.168.1.122:4918

$$end_record

SOLUZIONE

In questo caso lato OCS avevamo una Enterprise Edition con un singolo Front End e senza bilanciatore Hardware: questo tipo di configurazione, supportata in OCS, era bloccata in LCS 2005 SP1 e un apposito controllo verificava che due FQDN non si risolvessero con lo stesso indirizzo IP.

Nella guida alla migrazione è riportato infatti quanto segue:

Supporting a Pool with a Single Enterprise Edition Server :

If you deploy Office Communications Server 2007 Enterprise pool with a single Enterprise Edition server without a load balancer, to support coexistence you must use a separate IP address for the Enterprise server and the Enterprise pool.

To do so, the following steps are required:

Add a second IP address on the Enterprise Edition server
Point the DNS record for the Enterprise pool to the second IP address

This requirement exists because Live Communications Server 2005 SP1 servers cannot successfully communicate if the Enterprise Edition server and the Enterprise pool have the same IP address.

After your deployment is moved completely to Office Communications Server, you can remove the new IP and use a single IP address for the pool (and the pools DNS record) and the Enterprise Edition server.

Per risolvere il problema abbiamo quindi aggiunto un secondo IP sulla macchina di Front End OCS e fatto puntare l’ FQDN del Pool a questo nuovo indirizzo, e una volta riavviati i servizi il problema è sparito.

Esiste un articolo di KB di riferimento per questa problematica ormai nota:
Presence information appears as "Presence Unknown" when Live Communications Server 2005 users view the presence information of Communications Server 2007 users

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS - Remote Connectivity Analyzer

itentblg — Mon, 03 Aug 2009 02:00:00 GMT

Sulla scia del successo ottenuto dall’Exchange Remote Connectivity Analyzer (creato da Shawn McGrath e Brad Hughes), Premal Gandhi, Matthew Fresoli e Jason Stine hanno scritto un tool complementare per OCS: Office Communications Server Remote Connectivity Analyzer.

Il tool è disponibile sul sito https://www.TestOcsConnectivity.com

Introduzione

L’Office Communications Server Remote Connectivity Analyzer è un sito dedicato agli Admin che vogliono testare l’accesso remoto alla loro infrastruttura OCS. Il sito simula l’accesso remoto di un client riportando l’esito del test e, nel caso di fallimento, fornisce i dettagli del problema e i suggerimenti necessari a risolverlo.

In questa fase il tool è in beta, al momento sono disponibili i seguenti test:

Office Communications Server Remote Connectivity
Office Communications Server Remote Connectivity con AutoDiscover

Caratteristiche future

Il tool nei prossimi mesi verrà integrato con:

Un maggior livello di informazioni diagnostiche;
Maggiori dettagli riguardanti il troubleshooting;
Ulteriori test e scenari.

Se avete feedback o suggerimenti al sito è presente il classico feedback link.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 R2 - Reperire le informazioni di configurazione

itentblg — Mon, 15 Jun 2009 02:00:00 GMT

Con Office Communicator 2007 R2 è possibile avere una schermata che riporta le informazioni di configurazione, in maniera del tutto simile a quella con cui si ottiene lo stato delle connessioni su Outlook 2007; basta tenere premuto il tasto CTRL e cliccare con il tasto destro del mouse sull’ icona del Communicator.

Comparirà una schermata simile a questa:

Per una dettagliata spiegazione di tutte le voci vi rimando all’articolo pubblicato nel blog ufficiale del team OCS.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 R2 - Il servizio Front End non si avvia dopo l’installazione della KB 967831

itentblg — Tue, 09 Jun 2009 02:00:00 GMT

La KB967831 dopo aver fermato i servizi OCS ed eseguito gli aggiornamenti, esegue il riavvio degli stessi compreso il Monitoring Agent (RtcQmsAgent).
Se quest’ultimo non è configurato, l’installazione fallisce e l’installer tenta un rollback degli aggiornamenti con conseguente fallimento del servizio di Front End.

Nei prerequisiti della KB è infatti riportato:

Tutti i servizi Office Communications Server devo essere avviati prima di provare ad installare l’aggiornamento. Dopo aver installato la fix, l’aggiornamento prova ad avviare i servizi Front-End di Microsoft Office Communications Server. Se il servizio Front-End di Microsoft Office Communications Server non può essere avviato, l’aggiornamento esegue un rollback. Verificare che i seguenti servizi siano avviati prima di installare l’aggiornamento:

Office Communication Server Front End Service - rtcsrv
Office Communication Server IM conferencing - rtcimmcu
Office Communication Server Telephony Conferencing - rtcacpmcu
Office Communication Server Monitoring Agent – rtcqms

Affinché il Monitoring Agent si avvii è necessario che l’ MSMQ (MS Messaging queue) sia presente sul server, per cui per risolvere il problema è sufficiente installare l’MSMQ e il MS Messaging Queue Server con i seguenti comandi:

ServerManagerCmd -i MSMQ-Services
ServerManagerCmd -i MSMQ-Server

Il seguente link Install and Configure Message Queuing (for Monitoring Server) riporta la procedura anche per Windows Server 2003.

Successivamente è necessario reinstallare la patch, che dovrebbe ora andare a buon fine.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Come verificare il contenuto dell’Address Book

itentblg — Mon, 08 Jun 2009 02:59:00 GMT

Durante il troubleshooting dei problemi legati all’Address Book, potrebbe essere comodo controllare il contenuto del file galcontacts.db.

L’“Offline Address Book” viene scaricato localmente da Office Communicator 2007 nella directory: %USERPROFILE%\AppData\Local\Microsoft\Communicator

Per poterlo convertire in un formato leggibile è sufficiente impostare la seguente chiave di registry:

[HKEY_CURRENT_USER\Software\Microsoft\Communicator]
"DumpContactsToCSVFile"=dword:00000001

Sul Communicator fate logout e poi nuovamente login: a questo punto basterà andare in Tools --> View Received Files per trovare l’address book in formato CSV.

Ricordatevi di togliere la chiave se volete usare View Received Files per i normali trasferimenti di file.

Nota: questo sistema non funziona sui client R2, un alternativa è l’utilizzo del tool abserver.exe da un prompt dei comandi.
Ad esempio:

abserver.exe -dumpfile “F-0bed.lsabs” c:\absdump.txt

fornendo in input un recente Full file (F-xxxx) che contenga quindi tutti i contatti.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support

Network Load Balancing – Unicast vs Multicast

itentblg — Mon, 29 Dec 2008 03:00:00 GMT

Nel primo post abbiamo visto le caratteristiche principali del Network Load Balancing (NLB), mentre in questo approfondiremo le modalità di funzionamento: Unicast e Multicast.

Come abbiamo visto nel precedente post, è fondamentale che tutti i nodi ricevano le richieste dei client destinate al Virtual IP assegnato al cluster. L’algoritmo, su ciascun host, potrà in questo modo processare le richieste e stabilire quale di questi sarà designato a gestire la richiesta, mentre gli altri semplicemente la scarteranno.

Entrambi i metodi permettono di raggiungere quest’obiettivo, vediamo come funzionano.

UNICAST

Questa è la configurazione di default ed è quella che la stragrande maggioranza dei nostri clienti adotta.
Quando questa modalità è abilitata, un MAC Address “virtuale” rimpiazza quello della NIC, per cui sia il Virtual IP (VIP) che l' IP dedicato (DIP) verranno risolti con questo nuovo indirizzo.

Il nuovo MAC Address avrà questa forma:
02-bf-WW-XX-YY-ZZ
dove WW-XX-YY-ZZ è il valore esadecimale del VIP.

Al fine di distribuire le richieste per il VIP a tutti i nodi, e per evitare che l’utilizzo di un unico MAC Address per tutti gli host del cluster causi un conflitto, NLB “maschera” il MAC di tutti i pacchetti in uscita.

Ogni nodo appartenente al cluster è identificato da un numero progressivo univoco configurabile da interfaccia grafica: il "masking" avviene sostituendo il secondo byte dell’indirizzo MAC virtuale con l' host ID del nodo, che sarà quindi diverso per ogni interfaccia che partecipa al cluster.

Ad esempio:

02-bf-0a-00-00-01 -> 02-09-0a-00-00-01

Diamo un’occhiata ad una ARP reply di una richiesta per il MAC address del VIP:

Come possiamo vedere nella risposta, il frame ethernet riporta il MAC address “mascherato” del nodo 2, 02:02:c0:a8:00:01; da notare invece che l’ ARP header mostra il MAC address del cluster 02:bf:c0:a8:00:01; ricordiamo che i router, e i client, controllano il MAC address presente nell' ARP header e non nell’ethernet header, mentre gli switch, per mappare un indirizzo ad una porta utilizzano quello contenuto nell’Ethernet header.

Quando un client dovrà raggiungere il Virtual IP del cluster, questo sarà risolto correttamente con il MAC virtuale comune a tutti gli host, ma lo switch non lo potrà mappare ad alcuna porta specifica e non avremo alcun conflitto sullo switch stesso.

Il vantaggio dell'Unicast è che funziona nella quasi totalità delle configurazioni senza particolari interventi sugli switch o i router.

L’unica accortezza è dovuta al fatto che la condivisione dello stesso indirizzo MAC non permette la comunicazione tra host, per cui occorre avere almeno due NIC; non avendole disposizione è possibile comunque aggirare il problema impostando su ogni nodo la chiave di registro “UnicastInterHostCommSupport” documentata dall'articolo KB898867.

Lo svantaggio principale dell’Unicast riguarda invece il flooding, che è però possibile limitare:

creando una VLAN dedicata al cluster che comprenda solo le porte a cui i nodi sono collegati;
collegando tutti i nodi ad un hub in cascata allo switch.

In questo caso il masking deve essere disabilitato da registry in modo che lo switch mappi il MAC address del cluster alla porta su cui è collegato l’hub.

Il metodo indicato non è sempre praticabile per grandi realtà ma può essere una soluzione con cluster di piccole dimensioni.

Il parametro da impostare nel registry è "MaskSourceMAC":

Windows 2000: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters
Windows Server 2003: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\<GUID>

MULTICAST

In Multicast mode l'indirizzo MAC built-in non è disabilitato ma ne è aggiunto uno Multicast, in questo modo il VIP sarà risolto con il nuovo MAC mentre il DIP continuerà ad essere risolto con il suo MAC originario.

Il MAC Address generato ha questa forma:

03-bf-WW-XX-YY-ZZ

anche in questo caso WW-XX-YY-ZZ è il valore esadecimale del VIP

Riporto lo screenshot di una ARP reply di una richiesta per il MAC address del VIP:

Nell'ARP header notiamo il MAC del cluster con la forma 03:bf:c0:a8:00:01; l'indirizzo 00:15:5d:b0:d2:0a è in questo caso il MAC reale della NIC.

Il traffico Multicast è generalmente di default trattato come quello broadcast e quindi inoltrato su tutte le porte dello switch a meno di configurare manualmente lo switch. In Windows 2003, abbiamo però la possibilità di abilitare il protocollo IGMP (Internet Group Management Protocol), per cui basterà abilitare IGMP Snooping sullo switch e il traffico verrà instradato correttamente in automatico, eliminando il flooding.

Un ulteriore vantaggio di questa modalità risiede nel fatto che il MAC address reale viene ritenuto, permettendo di fatto il traffico tra host senza necessità di aggiungere una seconda scheda di rete.

Il principale svantaggio riguarda invece l’incompatibilità con alcuni device dovuta all’associazione Unicast IP address-Multicast MAC Address. Ad esempio i router Cisco non accettano tale mappatura e per far si che tutto funzioni è necessario aggiungere delle entry statiche a mano. Sul sito di Cisco è possibile reperire alcune indicazioni, ad esempio per quanto riguarda gli switch Catalyst: Catalyst Switches for Microsoft Network Load Balancing Configuration Example.

In conclusione, entrambe le modalità presentano vantaggi e svantaggi, ma la modalità di default Unicast è quella probabilmente più immediata da implementare. Chi volesse invece sfruttare IGMP per eliminare il flooding dovrà scegliere Multicast, tenendo a mente che alcuni apparati non accettano ARP reply per Unicast IP address che contengano un Multicast Mac Address e necessitano una configurazione manuale.

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Platforms Support

Network Load Balancing – Introduzione

itentblg — Mon, 22 Dec 2008 03:00:00 GMT

Questo è il primo di una serie di post in cui parleremo di NLB: Network Load Balancing.

Nella prima parte faremo un’introduzione delle caratteristiche principali di questa tecnologia, mentre nelle successive ci focalizzeremo più in dettaglio su alcuni aspetti tecnici.

Panoramica generale

NLB è una tecnologia cluster implementata a livello di sistema operativo e disponibile in Windows Server 2000, 2003 e 2008.

Lo scopo principale è fornire scalabilità e alta disponibilità a servizi e applicazioni basati su TCP/IP come Internet Information Services (IIS), Virtual Private Networking (VPN), Internet Security and Acceleration (ISA) e Terminal Services (TS).

I servizi da bilanciare dovranno essere configurati in maniera identica su ogni host che partecipa al cluster NLB, e le richieste da parte dei client saranno gestite dai singoli server in base all’algoritmo di bilanciamento.

Le principali caratteristiche dell’NLB in Windows Server 2003 sono:

High availability
Efficiency
Scalability
Ease of maintenance

In Windows Server 2008 sono state introdotte e migliorate molte funzionalità tra cui le principali sono:

Supporto a IPv6
Supporto a NDIS 6.0
Migliore integrazione con ISA Server

La tecnologia NLB è in grado di fornire una soluzione economica e alternativa ai bilanciatori hardware e per le sue caratteristiche, l’utilizzo ottimale avviene in presenza di scenari con un grande numero di client e servizi stateless.

Architettura

NLB è un NDIS intermediate filter driver inserito tra la scheda di rete fisica (NIC) e i protocolli dello stack TCP/IP come illustrato nella seguente immagine:

In Windows Server 2008 il driver è stato totalmente riscritto adottando il nuovo Lightweight Filters Driver model (LWF) che ha portato a miglioramenti nelle performance del driver stesso, mantenendo la retro compatibilità con le versioni NDIS precedenti.

Il driver deve essere installato su ogni server che partecipa al cluster, e agirà effettivamente come un rule-based filter per il traffico in ingresso verso l’host.

L'architettura così distribuita elimina la necessità di indirizzare le richieste verso un host specifico, il processo è quindi più veloce rispetto a ricevere, analizzare, riscrivere e rispedire le richieste; inoltre permette di massimizzare la disponibilità delle risorse: N host forniscono N-1 possibilità di failover mentre un classico dispacher deve essere ridondato per non creare un single point of failure.

Network Load Balancing automaticamente rileva e ricompone il cluster se un server ha un malfunzionamento o è disconnesso dalla rete, ma non è consapevole dello strato software che ha sopra, per cui i servizi e le applicazioni non vengono monitorate dal driver che continuerà a fare il suo lavoro anche se una di queste ha un qualsiasi problema. Per avere un monitoring delle applicazioni e dei servizi bilanciati bisogna ricorrere a dei software di management quali il Systems Center Operations Manager.

Algoritmo

L'algoritmo mappa le richieste dei client ad uno specifico host in base ad alcuni parametri, tutti gli host eseguono quest'operazione contemporaneamente per determinare quale di loro sarà designato a gestire la richiesta mentre gli altri la scarteranno.

L'algoritmo utilizzato da NLB è proprietario e quindi non è disponibile della documentazione pubblica che ne illustri il funzionamento, ma ci sono alcuni parametri che possono essere modificati per influenzare la distribuzione delle richieste:

Host priorities
Multicast o Unicast mode
Port rules
Affinity
Load percentage distribution
Client IP address
Client port number
Other internal load information

Il mapping rimarrà valido fino ad un eventuale cambiamento del numero di nodi o delle regole impostate.

Una nota importante per un corretto funzionamento dell’algoritmo: è essenziale che tutti i nodi ricevano le richieste in ingresso in quanto il processo decisionale per servire i client avviene separatamente su ogni singolo host.

Nei prossimi post vedremo le modalità di funzionamento Unicast e Multicast.

Maggiori informazioni e approfondimenti:

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Platforms Support