Mostrando entradas con la etiqueta Message Analyzer. Mostrar todas las entradas
Mostrando entradas con la etiqueta Message Analyzer. Mostrar todas las entradas

sábado, 21 de febrero de 2015

Tips de Troubleshooting para People Picker de Sharepoint

Voy a mostrar algunos tips útiles para verificar el funcionamiento correcto del People Picker de Sharepoint.

Entorno (montado sobre Azure):

  • AD: Windows Server 2012
  • 1 Granja (1 WFE, 1 App Server, 1 SQL Server)
  • Sharepoint 2013 SP 1, CU de febrero 2015

El people picker de Sharepoint es el responsible de consultar el AD en búsqueda de usuarios (accounts) y grupos, se usa para dar permisos a los sitios de Sharepoint.

imageimage

En este link podrás ver todas las configuraciones posibles del People Picker.

En este link y en este podrás ver la secuencia que se realizar cuando haces un “check name” en el people picker. En 50 pasos ves cómo funciona el people picker.

Algunos pasos resumidos:

  • Cuando haces una consulta en el people picker, el WFE consulta via una DNS Query al Global Catalog Service (se llama “LDAP Global Catalog Search Request”)
  • En esta query, se pregunta por usuarios y grupos que tengan un string de búsqueda (wildcard search).
  • Cuando se busca en el AD, se busca por los siguientes atributos

# User objects: 'name', 'displayName', 'cn', 'sn', 'SamAccountName', 'mail', 'proxyAddresses'

# Group objects: 'name', 'displayName', 'cn', or 'SamAccountName' attributes.

Ahora mostremos algunos tips útiles para hacer throu

1-Evaluar la conectividad desde el WFE hacia el Global catalog.

Supongamos que estamos en el dominio “contoso.com”.

image

Supongamos que estamos buscando todas las cuentas que tengan “sp” en el display name o en el atributo “SamAccountName”. Sharepoint cómo les comenté buscará en varios atributos del container de usuarios y grupos de AD (user Objects y groups Objects)

Supongamos que también buscamos por un grupo específico (Ej: que tengan en el display name “Domain”). En amarillo las líneas más importantes.

El siguiente query (descargar) nos permite evaluar la conexión contra nuestro el AD, buscando un usuario y un grupo (usando wildcards). La funcionalidad es parecida a cómo busca Sharepoint.


function SearchUsers($cn) {   
   $strFilter = "(&(objectClass=User)(cn=$cn))" 
   $objDomain =New-Object System.DirectoryServices.DirectoryEntry("LDAP://CONTOSO")
   $ds = New-Object System.DirectoryServices.DirectorySearcher 
   $ds.SearchRoot = $objDomain 
   $ds.PageSize = 1000 
   $ds.PropertiesToLoad.Add("displayName") 
   $ds.PropertiesToLoad.Add("name") 
   $ds.PropertiesToLoad.Add("cn") 
   $ds.PropertiesToLoad.Add("sn") 
   $ds.PropertiesToLoad.Add("SamAccountName") 
   $ds.PropertiesToLoad.Add("mail") 
   $ds.PropertiesToLoad.Add("proxyAddresses") 
   $ds.Filter = $strFilter 
   $ds.SearchScope = "Subtree"   
   Write-Host " >> Buscando usuarios: " $cn 
   $colResults = $ds.Findall()
   foreach ($usrTmp in $colResults)
    {
      Write-Host $usrTmp.Properties["name"]
    }

function SearchGroup($cn) {   
   $strFilter = "(&(objectClass=group)(cn=$cn))" 
   $objDomain =New-Object System.DirectoryServices.DirectoryEntry("LDAP://CONTOSO")
   $ds = New-Object System.DirectoryServices.DirectorySearcher 
   $ds.SearchRoot = $objDomain 
   $ds.PageSize = 1000 
   $ds.PropertiesToLoad.Add("displayName") 
   $ds.PropertiesToLoad.Add("name") 
   $ds.PropertiesToLoad.Add("cn") 
   $ds.PropertiesToLoad.Add("sn") 
   $ds.PropertiesToLoad.Add("SamAccountName") 
   $ds.Filter = $strFilter 
   $ds.SearchScope = "Subtree"    
   Write-Host " >> Buscando grupos: " $cn 
   $colResults = $ds.Findall()
   foreach ($usrTmp in $colResults)
    {
      Write-Host $usrTmp.Properties["name"]
    }
}

$startDTM = (Get-Date)
SearchUsers("*sp*") 
$endDTM = (Get-Date)
"La consulta tardo: $(($endDTM-$startDTM).totalseconds) segundos"

$startDTM = (Get-Date)
 SearchGroup("*domain*") 
$endDTM = (Get-Date)
"La consulta tardo: $(($endDTM-$startDTM).totalseconds) segundos"
 

Cuando lo ejecuto me retorna lo siguiente.

image

image

Es cómo si hubiera hecho esto.

image

image

Este script nos permite evaluar la performance de búsqueda de perfiles y grupos contra nuestro Global Catalog. Cómo pueden ver los tiempos son muy buenos.

2-Evaluar la conectividad mediante Message Analyzer

Ejecuto lo siguiente en la línea de comandos (run as a administrator)

netsh trace start persistent=yes capture=yes tracefile=C:\nettrace-sharepoint.etl

image

Después realizo algunas querys desde el People Picker, ej: sp_

image

Después detengo el trace.

netsh trace stop

image

Abro el Message Analyzer cómo administrador (run as a administrator)

Selecciono New Session / Files

image

Agrego el archivo del trace

image

En la sección de filtros agrego lo siguiente: contains "displayName"

image

En los mensajes veo que las query al AD, en el sumary dice:

Search Operation Search For RootDSE

Cuando entro a un mensaje, por ejemplo 1003

image

Hago click en el atributo LDAP.

En filter dice lo siguiente

(((objectCategory == person) && ((SubstringFilter{Type=anr,SubStrings=[Sp_]}) || (SubstringFilter{Type=SamAccountName,SubStrings=[Sp_]}))) || ((objectCategory == group) && (MatchingRuleAssertion{MatchingRule=1.2.840.113556.1.4.803 (LDAP_MATCHING_RULE_BIT_AND),Type=groupType,MatchValue=2147483648,DnAttributes=False}) && ((SubstringFilter{Type=anr,SubStrings=[Sp_]}) || (SubstringFilter{Type=SamAccountName,SubStrings=[Sp_]}))))

Pero si entro en más detalle, en la parte de Filter, veo que tiene dos contenidos (objectCategory==person y objectCategory==group). Es decir en la misma query, consulta por usuarios y grupos que coincidan con “sp_”

image

Los atributos que cargo en la query son

image

Si filtro solamente el mensaje 1003 vero que el tiempo que tardo en hacer la consulta fue de 0.0024204 ms

image

Y necesitó 4 paquetes para obtener los resultados

image

El AD (10.0.0.4) le retorno 3 paquetes, si ven en el summary, ven que dice LDAP Message, Search Result Entry, MessageID: 43

image

Si ves el field data, podes ver que aparece (SP_farm y SP_setup) lo mismo que buscaste por Sharepoint

image

image

Algunos links útiles:

http://thesharepointfarm.com/2014/01/people-picker-troubleshooting-tips/

sábado, 30 de agosto de 2014

netsh–Una manera simple de hacer network trace sin instalar nada en nuestros ambientes de Sharepoint

A partir de Windows 7/2008R2 vino una tool llamada netsh para realizar traces de nuestras placas de red (entre otras cosas de este comando).

http://technet.microsoft.com/en-us/library/dd878517%28v=ws.10%29.aspx

Aplica a: Windows Server 2012|2012 R2, Windows 8|8.1, Windows Server 2008R2, Windows 7

Probado sobre: Sharepoint 2013 SP1, CU agosto, Windows Server 2012, Azure VM (A6 instance)

Algunas ventajas de este comando:

  • No instalo nada en mis servers, ya viene incluido dentro de mi SO
  • Permite tracing persistentes, esto es, incluso con reboots, el trace sigue funcionando
  • Nos permite enfocar el trace en un escenario específico (Ej: dns, lan, dhcp, etc)
  • Los paquetes generados del trace (ETL) pueden ser abiertos por Wireshark, Network Monitor o Message Analyzer
  • Podemos ver reportes rápidos del trace (.cab)

Primero vemos que escenarios (conjunto de providers de trace) tenemos:

netsh trace show scenarios

image

Si nos interesa algún escenarios específico, podemos ejecutar

netsh trace show scenario lan

image

Pueden tener más providers con este comando: netsh trace show providers >c:\providers.txt

Revisando este archivo, veo que hay providers de Sharepoint

{0119F589-72D7-4EC3-ADF5-1F082061E832}    Microsoft-SharePoint Products-Web Content Management
{137DEDCF-DAEC-4E65-A6BC-02212AECD32F}    Microsoft-SharePoint Products-Office Automation Services
{1C415899-58B3-4BFC-9236-105E7FD38719}    Microsoft-SharePoint Products-SharePoint Foundation Search
{252BB337-A7F5-413F-9B03-F36FA4F18EF8}    Microsoft-SharePoint Products-Business Connectivity Services
{278E40D0-FDAA-4EB4-AB6B-9E0AD6BDBE79}    Microsoft-SharePoint Products-Excel Services Application
{38BB51E9-CF75-40CA-92CC-49E22F935F65}    Microsoft-SharePoint Products-Visio Graphics Service
{4CB0A010-80C2-4CDF-BB9D-8B7E923FAC8F}    Microsoft-SharePoint Products-Access Services 2010
{4F33CA13-30A4-4AF2-AEB7-DE59AA6C2563}    Microsoft-SharePoint Products-Services Infrastructure
{5311B1CA-DDE7-408B-A097-F7A1BF5BB170}    Microsoft-SharePoint Products-Access Services
{6FB10E7F-F8EF-44A7-9678-25744648F92C}    Microsoft-SharePoint Products-Document Conversions
{6FB7E0CD-52E7-47DD-997A-241563931FC2}    Microsoft-SharePoint Products-SharePoint Foundation
{73541538-24DA-4282-AE1C-3A6321C23FB8}    Microsoft-SharePoint Products-Secure Store Service
{8B3DDD3D-2B09-4669-BF81-E2D6921FEEEA}    Microsoft-SharePoint Products-SharePoint Portal Server
{A3499A35-DB34-421A-94FC-4D76522BEAB3}    Microsoft-SharePoint Products-InfoPath Forms Services
{A7CD5295-CBBA-4DCA-8B67-D5BE061B6FAE}    Microsoft-SharePoint Products-PerformancePoint Service
{B9499A35-DB34-421A-94FC-5A8DBBBC4228}    Microsoft-SharePoint Products-Education
{BAFFAE3D-E80A-4219-B41F-5760B7CEC473}    Microsoft-SharePoint Products-Shared
{C33B4F2A-64E9-4B39-BD72-F0C2F27A619A}    Microsoft-SharePoint Products-SharePoint Server
{C544CCCA-DCAA-416D-B91B-E639B8B28589}    Microsoft-SharePoint Products-Word Automation Services
{C8263AFE-83A5-448C-878C-1E5F5D1C4252}    Microsoft-SharePoint Products-SharePoint Server Search
{C8A9829C-C62B-46CD-AACF-95788DE23730}    Microsoft-SharePoint Products-SharePoint Translation Services
{D191778A-DFE4-11DE-A777-F8AD55D89593}    SharePoint Express
{E0E675CD-EA07-450D-9841-786EAC9A9812}    Microsoft-SharePoint Products-eApproval
{F78D66EC-09A9-42A2-AC7A-5EE2062DE7E4}    Microsoft-SharePoint Products-Document Management Server

Si yo quisiera ver un provider específico, ejecuto lo siguiente:

netsh trace show provider name="Microsoft-SharePoint Products-SharePoint Portal Server"

image

Estos providers nos permite enforcarnos en un trace espcífico, ej: search de Sharepoint

Ej: netsh trace start persistent=yes capture=yes tracefile=c:\temp\nettrace-search.etl" provider="Microsoft-SharePoint Products-SharePoint Server Search"

En este post, no me voy a enfocar en un escenario específico, sólo haré un trace de todo el tráfico del servidor de Sharepoint

Para ello ejecuto el siguiente comando:

netsh trace start persistent=yes capture=yes tracefile=C:\Temp\nettrace-sharepoint.etl

recuerda revisar que tengas espacio suficiente en el directorio. Por default usará 250 MB.

Acá tenés todos los parámetros del comando: http://technet.microsoft.com/en-us/library/dd878517%28v=ws.10%29.aspx#bkmk_traceStart

http://msdn.microsoft.com/en-us/library/windows/desktop/dd569142%28v=vs.85%29.aspx

Considera en principio los siguientes: level, maxSize

image

image

Ahora navego un poco el sitio de Sharepoint, y después de 10 minutos ejecuto el siguiente comando para detenerlo.

netsh trace stop

image

Veo que se generaron los dos archivos

image

Si yo ingreso al archivo .cab, veo un montón de archivos.

image

Si abro el archivo report.html (selecciona todos los files –> extract), nos muestra un montón de información del trace

image

Si selecciono un item, por ejemplo “DNS Information” veo más info

image

Los que nos importa es ver el archivo .etl con alguna tool de red. Exporta tu archivo .etl a tu máquina, y abre el archivo con Wireshark, Message Analyzer o Network Monitor

Por ejemplo mediante Message Analyzer (Browse)

image

Después selecciono Analysis Grid/Sequence Match

image

Veo el diagnóstico de los paquetes de red

image

Ej: veo 3 segmentos perdidos

Si cambio la vista “Analysis Grid”

image

Veo todos los paquetes del trace

image

Si yo aplico un filtro (tcp.port==80)

image

Si yo le aplico otro filtro (add destination to filter)

image

y aplico el filtro (cambia or por and)

image

Veo lo que me interesaba, filtrar los paquetes relacionados a mi sitio de Sharepoint

image

Cómo pueden ver tengo un montón de paquetes con status 401

image

Si yo me enfoco en un message number (648), veo que hubo dos paquetes en esta operación

image

Message Number 648: mi solicitud al Sharepoint montado sobre Azure

image

Algunos parámetros útiles del message number:

Method: Get

Host: chrissp2013dev.cloudpapp.net

Referer Url y User-Agent

image

Message Number 649: la respuesta del servidor de Sharepoint

image

Algunos parámetros útiles del message number:

StatusCode: 401 (unauthorized)

MicrosoftSharePointTeamServices: 15.0.0.4551 (es la versión de Sharepoint que está corriendo sobre Azure IaaS)

request-id o SPRequestGuid: 9094b39c-ee71-007a-0000-011f7b37ee10 (es el GUID asociado en los ULS logs)

Si yo reviso los logs mediante ULS Viewer, veo la solicutud

image

SPIisLatency: 0 (es el queue time del IIS antes de pasarle la solicitud a Sharepoint)image
SPRequestDuration: 3 (es el tiempo que tardo Sharepoint en procesar la solicitud )

La misma información la pueden procesar con Wireshark o Network Monitor.

Para mayor información sobre netsh, consulta este post, muy buen repaso por todos los componentes del trace: http://chentiangemalc.wordpress.com/2012/02/22/netsh-traceuse-it/

domingo, 10 de agosto de 2014

Time to first byte en Sharepoint 2013

Time To First Byte o TTFB es una medida que se usa muy a menudo para evaluar la respuesta del servidor. Cuando se solicita una página (GET), el server devuelve un ACKs (acknowledgement) de la solicitud al usuario. Mientras tanto el servidor procesa el request, cuando el servidor envía el primer paquete de datos al cliente, ese tiempo entre que se envío el ACK y el primer paquete de datos, se llama TTFB (Time to first Byte)

image

Importante: no siempre un tiempo corto indica buena performance, por ejemplo, cuando se usa gzip para comprimir el request envíado al cliente, se suele tener TTFB altos, pero una excelente performance. Esta medida nos permite tener una idea donde puede estar el problema, pero siempre se debe evaluar otros parámetros, por ejemplo: latencia de la red. Les recomiendo el el post sobre Message Analyzer:

http://todosharepoint.blogspot.com.ar/2014/07/evaluar-la-performance-de-la-red.html

http://todosharepoint.blogspot.com.ar/2014/07/evaluar-la-performance-de-la-red_13.html

http://todosharepoint.blogspot.com.ar/2014/07/evaluar-la-performance-de-la-red_4920.html

En este post le voy a mostrar cómo puedo calcular el TTFB con IE, Fiddler, y Chrome

En IE, presiono F12 y voy a la solapa de network

image

Después elijo el request que hice sobre la página, y selecciono el tab de “DETAILS”

image

Después selecciono el tab de “Timings”

image

El atributo “Request” es el que nos indica el TTFB (time to first byte)

Con Fiddler se debe seleccionar el request y sacar la diferente entre “ServerGotRequest” y “ServerBeginResponse”. En este caso fue 20:05:33.915 - 20:05:34.199 = 0.284 ms. Como pueden ver varía de los tiempos de IE, posiblemente ya estaba cacheado el DNS y la solicitud en el Server.

image

En chrome se debe seleccionar Network, y ver el parámetro “Waiting”

image

Importante: cuando el pool del Web Application esté detenido o se haya hecho un recicle del pool, el TTFB  suele ser alto.

Recomendación: registra en tu documentación de la granja los tiempos de TTFB de una página standart y todos los tiemposdel request (ej: response time), de esta manera tendrás un parámetro de consulta cuando tengas problemas de latencia sobre Sharepoint.

Tip adicional: usaremos Microsoft Visual Round Trip Analyzer (http://www.microsoft.com/en-us/download/details.aspx?id=21462 ) para evaluar el network round trip entre el cliente y el servidor. Requiere tener instalado Netmon 3.4.

Hago una captura con Netmon accediendo a la página de Sharepoint

image

Guardo el archivo .cap

image

Después abro Microsoft Visual Round Trip Analyzer, y elijo el archivo .cap guardado previamente.

image

image

La solapa de Analysis nos da un par de parámetros o reglas que se aplican al registro de paquetes de red. Si pones el mouse arriba de la regla, te da más información

image

image

image

Si pones el mouse arriba de la regla te da más información:

image

image

En la solapa de “All Files”, nos da más información. Ej: Time to 1st Byte

image

También información de los frames.

image

Mucha de la información de  Netmon y Microsoft Visual Round Trip Analyzer, se juntaron en el nuevo Message Analyzer. http://www.microsoft.com/en-us/download/details.aspx?id=40308

Links útiles:

Script de Powershell para generar monitorear por un período de tiempo: http://blogs.msdn.com/b/besidethepoint/archive/2010/05/01/calculate-time-to-first-byte-with-powershell-script-ping-url.aspx 

Psping para evaluar latencia: http://blogs.msdn.com/b/igorpag/archive/2013/12/15/azure-network-latency-test-and-sql-server-optimization.aspx

http://msdn.microsoft.com/en-us/magazine/dd188562.aspx