Impersonalización y .net Framework .4

Sintomas:
Cuando en .net framework 4 usamos la impersonalización

Podemos recibir errores que van desde
No se puede cargar el archivo o ensamblado 'AjaxControlToolkit' ni una de sus dependencias. Acceso denegado.
hasta:
La identitad actual  (dominio\usuario) no tiene derechos de escritura en 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files.'
pasando por un mensaje tan significativo como
Líneas de código fuente no relevantes


Solución:
En muchos foros se recomienda darle permisos full control o lectura escritura al usuario en este directorio.
En producción (Windows server 2008 R2 con IIS7.5 yo he preferido añadir al usuario en cuestión en el grupo IIS_IUSR.
En cuanto al servidor de desarrollo sigo pegandome con ello, aunque puedo trabajar sin el impersonate.
Comentario:
Como dicen en: http://www.devjoker.com/contenidos/catss/454/Liacuteneas-de-coacutedigo-fuente-no-relevantes.aspx

"Es mejor no decir el tiempo que se pierde con estas tonterías."

La busqueda no funciona en Sharepoint Foundation (y versiones anteriores)

Sintomas:
En uno de tus sitios no funciona la busqueda y tienes un error como este:
No se puede rastrear la dirección de inicio sts4://sede.ascer.es/contentdbid={dcfdf837-58f4-432e-856f-6318f2fe8ff6}.
Contexto: aplicación 'Archivo_de_índice_de_búsqueda_en_el_servidor_de_búsqueda', catálogo 'Search'
Detalles:
Acceso denegado. Compruebe si la cuenta predeterminada de acceso al contenido tiene acceso a este repositorio, o bien agregue una regla de rastreo para rastrear este repositorio. Si el repositorio rastreado es un repositorio SharePoint, compruebe si la cuenta usada tiene permisos completos de lectura en la aplicación web de SharePoint que se está rastreando. (0x80041205)
Resolución:
Comprueba que puedes acceder al sitio en cuestión desde la maquina que lo aloja. En caso negativo es muy posible que este relacionado con la protección contra loopbak del IIS
Mira este vinculo para ver como resolverlo:
http://support.microsoft.com/kb/971382/en-us

Visualizar mi calendario de Exchange desde Sharepoint (versiones 2010)

Problema:
Acceder a un calendario almacenado en Exchange Server (Outlook) desde SharePoint.
Solución:
Crear un calendario
Viendo el calendario ir a Calendario/Superposición de calendarios (overlay).
Añadir el calendario.
Mas detalles en:
http://office.microsoft.com/en-us/sharepoint-foundation-help/work-with-multiple-exchange-and-sharepoint-calendars-in-one-sharepoint-calendar-HA101777171.aspx
Mas problema:
Una vez hecho esto al sincronizar podemos tener dos problemas relacionados con el OWA.
a)  No se puede establecer una relación de confianza con el canal TTL /SSL (Could not establish trust relationship for the SSL/TLS secure channel with authority).
b)Para autenticarse el sitio OWA utiliza HTTP mientras que SharePoint require NTLM.
Todo esto puede estar relacionado con que publicas el OWA mediante forefront TMG con un certificado de terceros.
Lo mejor si tienes los servidores en tu red privada es que utilices la url interna.
En mi caso redirigía a la url externa por lo que tuve que usar el mandato:
set-OwaVirtualDirectory -identity "owa(Default Web Site)"  redirecttooptimalOWAServer=false
Aun así cada dos por tres cambia la url por la pública.
En cualquier caso el problema a) se resuelve configurando sharepoint para que confie en la autoridad raiz del certificado público de OWA.
Otro problema que suge es que solo ves ocupado o libre, la solución está en dar permisos al usuario por defecto para que pueda ver el asunto (los permisos los das desde Outlook o con GPOs)
A dia de hoy (Noviembre 2010) no se puede acceder a otros calendarios como pueden ser los recursos

Get-Recipient error, controladores de dominio y Exchange

Sintomas:
La consola de Exchange 2010 da un error emergente que a su vez se refleja en el registro de aplicación con el siguiente texto.
La tarea Get-Recipient arroja una excepción de terminación en la etapa Microsoft.Exchange.Data.Directory.ADTransientException: Un error provocó un cambio en el conjunto actual de controladores de dominio.
Solución
Borrar:
C:\Users\User\AppData\Roaming\Microsoft\MMC\Exchange Management Console
Referencias:
Gracias a http://www.howexchangeworks.com/2010/06/error-caused-change-in-current-set-of.html

Credential Manager, HP y Windows Vista.

Sintomas:
No puedes hacer login en estación hp con windows vista porque no puede conectar con Credential Manager
Solución
Creo que lo mejor es desinstalar Credential Manager.
Haces login con el asistente, deshabilitas credential manager y desinstalas credential manager.
Las mejores instrucciones en:
http://www.tomstricks.com/how-tofix-the-system-could-not-access-the-credential-manager-server-in-windows-vista/

Traduzco las instrucciones que hay en esta página dado el interés que veo despierta este post:

En la pantalla de inicio de sesión de Windows Vista, haga lo siguiente:

• Seleccione la opción "iniciar sesión como usuario diferente"
• Haga clic en "iniciar sesión con Wizard". Esto abrirá una nueva ventana de conexión donde usted puede especificar nombre de usuario, dominio y contraseña.
• En la esquina inferior izquierda de la ventana hay un botón "Más" Hacer clic y marque la casilla "No iniciar sesión en Credential Manager"
• Escribe tu nombre de usuario, contraseña y dominio en los respectivos lugares e inicia sesión.
• Tras iniciar la sesión, desinstala Credential Manager!

Determinar la versión de un assembly en el GAC

Sintoma:
En ocasiones necesitamos saber la versión de un assembly para complimentar la entrada en el web.config.
Resolución:
Hay que usar la herramienta GACUTIL
gacutil /l system.web
La herramiente la  podemos encontrar en alguna de estas ubicaciones:

• %programfiles%\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe
• %programfiles%\Microsoft SDKs\Windows\v6.0\Bin
• %programfiles%\Microsoft SDKs\Windows\v6.0A\Bin
• %windir%\Microsoft.NET\Framework\v1.0.3705
• %windir%\Microsoft.NET\Framework\v1.1.4322

 Si os parecen muchas os diré en mi caso no estaba en ninguna de ellas sino en:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
Dado que uso el .vstudio10 con .net4.
Agradecimientos:
http://blogs.iis.net/davcox/archive/2009/07/14/where-is-gacutil-exe.aspx
http://forums.asp.net/t/1077367.aspx

Los proyectos en red no son de confianza para visual studio

Sintomas:
Cuando utilizas una unidad de red para almacenar tus proyectos, Visual Studio 2010 se queja al abrirlos porque las ubicaciones no son de confianza
Solución:
Hazla de confianza utilizando la utilidad CASPOL.EXE en una ventana de la línea de comandos abierta como Admininstrador
Sintaxis:
caspol -m -ag 1.2 -url urlname FullTrust
Ejemplo:
Ejecutando:
caspol -m -ag 1.2 -url \\servidor\recurso\proyectos\* FullTrust
Autorizaras todos los proyectos aalmacenados almacenados por debajo del directorio proyectos.
Mas información:
¿Donde está CASPOL?
CASPOL se encuentra en los directorios de las distintas versiones del framework:
C:\Windows\Microsoft.NET\Framework\vN.n.xxxxx
Y he usado la del 4.0
C:\Windows\Microsoft.NET\Framework\v4.0.30319
¿Por qué no usar Mscorcfg.msc? ¿Donde está Mscorcfg.msc?
Era lo habitual hasta la versión 2, pero desde entonces han dejado de distribuirlo con las versiones del framework posteriores, aunque se instalaba con Visual Studio.
Ahora con la versión 4.0 del framework incluso dicen que no está soportado, y ya no lo incluyencon Visual Studio 2010. Y solo queda usar CASPOL