Durante el proceso de actualización del agente de FCS, se presenta el mensaje de error "8024402f". Un poco de información más detallada apareció en el visor de sucesos:
ID: 5000
"EventType mptelemetry, P1 8024402f, P2 endsearch, P3 search, P4 1.5.1937.0, P5 mpsigdwn.dll, P6 1.5.1937.0, P7 microsoft forefront client security, P8 NIL, P9 NIL, P10 NIL."
Según pude leer en algunos sitios en internet, este tipo de errores se deben a problemas de comunicación con WSUS o el sitio de Windows Update, al leer esto, recordé que no implementé las políticas necesarias (GPOs) para que los PCs y servers de mi infraestructura detecten el servidor de WSUS; luego de crear dicha política y refrescarla con "gpupdate /force" y volver a ejecutar la actualización manual funcionó sin problemas.
Probando la nueva versión de Microsoft Application Virtualization (System Center Application Virtualization ó Softgrid Beta 4.5) sobre Windows Server 2008 en un ambiente de Terminal Services. El punto es que toda la instalación resultó sin problemas hasta que instalé el cliente de Application Virtualization para Terminal Services y al tratar de ejecutar la aplicación de prueba se presentó un mensaje de error indicando que el servidor rechazó las conexiones. Revisando los servicios de Windows Server 2008 verifiqué que "Softgrid Virtual Application Server" no estaba levantado y la tratar de hacerlo generaba el error "536912451" y sin información adicional.
Solucioné el problema desinstalando completamente Application Virtualization incluido el cliente de TS, borré también la base de datos creada en SQL Server 2005 SP2. También hice algunos cambios en la configuración de la instalación y de SQL que posiblemente hayan ayudado. Primero, en SQL Server Configuration Manager > SQL Server 2005 Network Configuration > Protocols for MSSQLSERVER habilité las opciones: Named Pipes, TCP/IP y VIA. En el proceso de instalación de Softgrid al ingresar los datos del servidor coloque el FQDN completo del servidor. Luego de instalar el Application Server, reinicié el servidor e instalé el cliente de TS, volví a reiniciar el servidor, probé con el cliente y la aplicación de prueba y todo funcionó, claro está que el servicio a pesar de que está configurado para iniciarse de manera automática no lo hace, hay que iniciarlo manualmente.
Configurando TS RemoteApp sobre Windows Server 2008 Enterprise obtuve este mensaje de error a nivel de estaciones de cliente accediendo por medio de IE a TS: "The Remote computer could not be found". La dirección que ingresé en el browser era del tipo http://server/ts ó http://192.168.0.1/ts, de ambos modos ingresé al sitio sin embargo al tratar de ejecutar una aplicación obtenía el mensaje de error antes mencionado. Al revisar las configuraciones en la consola de administración de TS (Terminal Server RemoteApp Manager) en la sección Overview, en Terminal Server Settings me di cuenta que estaba colocado el modo de acceso al servidor como server.midominio.local, intenté ingresar con el FQDN completo del servidor ejecutar la aplicación y todo funcionó sin problema.
El pasado sábado 26 de abril pude participar como speaker del evento de lanzamiento de comunidades de Windows Server 2008, SQL Server 2008 y Visual Studio 2008. Esta invitación llegó por parte de las comunidades técnicas de la ciudad de Manta. A pesar del poco tiempo disponible para hablar sobre Windows Server 2008, y como en otras oportunidades, enfatisé mi presentación en los cuatro pilares funcionales de Windows Server 2008: Seguridad, Web, Virtualización y fundamentos. Finalmente pude disfrutar de un día en Manta para descanso personal y recuperar fuerzas para la siguiente semana, un fin de semana que nunca se olvidará, gracias Manta y en especial a Byron Camino y Marcelo Ávila, líderes de las comunidades.
Para entender el problema es necesario explicar primero el escenario. Tres componentes básicos forman parte de la infraestructura montada: Directorio Activo, Exchange Server 2007, y un servidor firewall / proxy de frontera (que a su vez funciona como smarthost de correo elecrónico, entrante y saliente). Este smarthost mantiene las funciones de filtro de correos electrónicos para detectar virus y spam. El dominio utilizado para la comunicación y enrutamiento de correos electrónicos entre el smarthost y Exchange 2007 es completamente distinto al dominio público registrado en internet. Toda esta descripción se resume en la figura 1.
Figura 1
Luego de haber configurado todos los buzones de correo de los usuarios se procedieron a hacer las pruebas. El correo entrante funcionó si problemas, simplemente es necesaria una política de reenvío de correos electrónicos desde el smarthost a Exchange 2007. Sin embargo para los correos salientes es necesario configurar un "Send Connector" (Microsoft Exchange > Organization configuration > Hub Transport). Al configurar el "Send Connector" en la viñeta "Address space" agregué el nombre del dominio interno "miempresa.local" para que sea reconocido dicho dominio en el smarthost, sin embargo cuando traté de enviar un correo se presentó el mensaje de error dentro de la herramienta de "Queue viewer": "No se encuentra un conector coincidente para enrutar el destinatario externo.". Luego de indagar el problema me di cuenta, leyendo más detenidamente la descripción de "Address space" que ahí debían registrarse todos los dominios externos en internet a los cuales ese conector puede enviar correos pasando por el smarthost. Para que todo funcione sin problemas, cambié el "Address space" por el comodín * (asterisco), seleccioné la opción de todos los subdominios. hice la prueba nuevamente y en efecto funcionó. La aplicación de esta opción podría ser para restringir el envío de correos electrónicos hacia el internet en el caso de querer hacerlo así o que ciertos usuarios únicamente puedan enviar correos internamente.
Al tratar de ingresar a OWA de Exchange 2007 recibí este mensaje de error: "Could not load all ISAPI filters for site/service. Therefore startup aborted.". Al revisar los ISAPI Filters de las propiedades del sitio web por defecto donde se instalan los archivos y directorios de OWA apareció el filtro "Exchange OWA Cookie Authentication ISAPI filter" que no pudo cargarse, tal y como se muestra en la figura 1.
Figura 1.
Revisando en internet me encontré con este sitio: http://support.microsoft.com/kb/894435, y ejecuté los pasos descritos en la sección "ASP.NET 2.0, 64-bit version", luego de lo cual todo funcionó sin problema.
Una experiencia única el haber compartido con Roberth Hess, Jorge Oblitas, Edgar Sánchez y Francisco Lomas el .NET Show. En esta ocación pude hablar un poco acerca de escenarios de colaboración con Office System 2007, concentrándome principalmente en Sharepoint Server 2007 (colaboración on-line) y Groove 2007 (colaboración offline). En el caso de Sharepoint desarrollé un escenario de "aprobación de permisos de salida" en una organización utilizando listas personalizadas y flujos de trabajo (workflows) construidos con Sharepoint Designer 2007. En el caso de Groove 2007 integré esta herramienta con Sharepoint a nivel de bibliotecas de documentos y las capacidades de trabajo fuera de línea, más adelante colocaré en mi blog un artículo al respecto de como reproducir este escenario.Una vez más, gracias a Jorge por la invitación y el gran honor de haber compartido una mañana de tecnología con Roberth. Hess
Durante la implementación de CRM 3.0 en la empresa en la que actualmente trabajo, me encontré con algunos incovenientes, particularmente con la integración de CRM 3.0 con Exchange 2007. Uno de los componentes de CRM es el Email Router, que se encarga de la distribución y entrega de correos a los destinatarios correspondientes que forman parte de CRM; este componente está originalmente diseñado para dar soporte a Exchange 2000 y 2003. Para mi escenario, implementé Directorio Activo en un servidor con Windows Server 2003 64 bits y sobre este Exchange 2007. El primer obstáculo con el que me encontré es que el Email Router de CRM 3.0 no tiene soporte para Exchange 2007 por defecto, pero, si en la organización se mantiene originalmente un servidor Exchange 2000 ó 2003 y adicionalmente un Exchange 2007, existe una actualización de CRM 3.0 Email Router para poder interactuar con Exchange 2007, pero no es equivalente al Email Router propiamente dicho, es decir, no se puede instalar sobre un servidor Exchange 2007. En mi caso como no tengo un Exchange 2003 previo simplemente no puedo consumir la funcionalidad de este componente. Las buenas noticias son que CRM 4.0 si tiene soporte completo para Exchange 2007. Para aquellos que deseen esta actualización del Email Router de CRM 3.0 aquí está el link: http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=f7656f0f-4195-4a7d-b654-2786787e1422
El segundo obstáculo que tuve fue la momento de dar soporte a los usuarios que mantienen instalado Office 2007, específicamente Outlook 2007 (instalación del cliente de CRM 3.0 para clientes Outlook). Para esto si pude encontrar solución, y el enlace está aquí: http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=740e1b3b-11c3-4aef-b2e3-8309e0cf1bb0
Finalmente todos mis usuarios trabajan en un ambiente de Terminal Services para lo cual también encontré una actualización y poder instalar el cliente de CRM para outlook, aquí el enlace: http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=cbad1af7-8fde-40f2-8df5-935a363f87d9
Espero esta información sea de su utilidad.
El día de ayer, 1 de abril, fue un día realmente especial por dos razones; en primer lugar por la realización del evento de lanzamiento de Windows Server 2008, Visual Studio 2008 y SQL Server 2008 en la ciudad de Quito, donde participé como speaker de la sesión de seguridad en el track de IT Pros, aunque con un "poco" de inconvenientes técnicos pues logré salir algo librado del tema, sin embargo quedé en deuda con todo el público asistente y de hecho voy hacer algo con la ayuda de este blog para compensarlo.
El segundo motivo de haber sido un gran día fue el recibir la noticia de haber sido reconocido por tercer año consecutivo como MVP (Most Valuable Professional) en Windows Server Customer Experience. Un nuevo año de esfuerzo, dedicación y ganas. Mis más sinceros agradecimientos a Fer García (MVP Lead), Guillermo Taylor (MSFT) y todas las comunidades técnicas y demás colegas y amigos MVPs, a todos ellos dedico este reconocimiento. En la foto, los héroes de la jornada.
En muchos de los casos, cuando se desarrolla una imagen de Windows CE a la medida, se requiere incluir ciertos archivos que no son propios del sistema operativo, tal como: archivos de configuración, aplicaciones, entre otros. En este caso particular yo tuve que incluir un archivo de configuración para una conexión remota utilizando Remote Desktop Connection y una aplicación personalizada. Para incluir cualquier tipo de archivo a una imagen NK.BIN de Windows CE se necesitan dos componentes:
- Editar el archivo project.bib
- Una carpeta local donde se ubiquen los archivos a importar o incluir en la imagen NK.BIN
Inicialmente para el archivo de configuración (.rdp) utilice la opción del Platform Builder: Project > Insert > Resource, luego seleccioné la opción "Import", luego edité el archivo project.bib y coloqué la entrada correspondiente al archivo (esto lo voy a explicar más adelante), generé la imagen y en efecto funcionó. Sin embargo, para la aplicación (.exe) este proceso no funcionó. El proceso de importación simplemente no funcionó, por lo que recurrí al plan "B". Creé una carpeta en la raíz C:\ y coloqué ahí la aplicación, modifiqué la entrada correspondiente en el archivo project.bib y listo. No se porque razón no funciona con aplicaciones pero al final funcionó.
Las entradas a las que me refiero en el archivo project.bib tienen el siguiente formato:
Name Path Memory Type
default.rdp $(_FLATRELEASEDIR)\default.rdp NK S
app.exe c:\archivos\app.exe NK S
Por defecto cuando se utiliza la opción "Import" el archivo se importa en la carpeta "Release" donde se genera la imagen del sistema operativo, es por esa razón que para el archivo default.rdp se utiliza la constante $(_FLATRELEASEDIR) que hace referencia a ese path. Para la aplicación app.exe, como había escrito, se debe crear una carpeta aparte y colocar ahí el archivo y especificar el path completo.
Luego de varios días de investigación, posts en blogs, preguntas al fabricante etc etc, lo logré. El escenario es el siguiente: por defecto la opción de "Disk drives" de la viñeta de "Local Resources" de Remote Desktop Connection no viene marcada y de hecho esta configuración por alguna razón no se guarda en el registro; otra información como nombre/IP del servidor remoto, nombre de usuario, contraseña, dominio si se guardan al grabar el registro. Revisé varios blogs donde mencionaban algo sobre el tema pero definitivamente no funcionó.
Al final lo que hice fue generar un archivo default.rdp marcando únicamente la opción de "Disk drives" y lo agregué como archivo del sistema al momento de generar la imagen nk.bin de Windows CE. Específicamente no se como opera el tema, pero cuando inició el sistema operativo Windows CE e hice doble clic en el acceso directo a "Remote Desktop Connection" apereció marcada la opción de "Disk drives" y todo funcionó bien. Asumo que si se requiere que vayan marcadas algunas otras opciones se debe seguir el mismo procedimiento, pero hay que tomar en cuenta que si se desmarca la opción esto no se guardará.
Toda lista de Sharepoint posee formularios por defecto para la creación (NewForm.aspx) y modificación (EditForm.aspx) que se encuentran ligados a la barra de herramientas de la lista o al desplegar el menú de un item ya creado. En muchos de los casos estos formularios por defecto deben ser cambiados por formularios personalizados. Para cambiar estos formularios por defectos de las listas de Sharepoint he utilizado Sharepoint Designer. Para esto seguir los siguientes pasos:
- Previamente diseñar los formularios personalizados con los campos requeridos.
- Ejecutar Sharepoint Designer y conectarse al sitio donde se encuentren implementadas las listas.
- Hacer clic derecho sobre el nombre de la lista que se desea cambiar los formularios por defecto y seleccionar "Propiedades".
- En el cuadro de diálogo de propiedades de la lista, hacer clic en la viñeta "Archivos auxiliares".
- En la opción "Formularios específicos del tipo de contenido:" seleccionar "Elemento".
- Aparecen tres formularios en la parte inferior: de mostrar elementos, de nuevo elemento, y de editar elementor. Debajo de cada opción existe una linéa de texto deshabilitada indicando cual es el formulario por defecto, junto a esta línea de texto aparece un botón de "Examinar..." el mismo que debe ser presionado para seleccionar el formulario que reemplazará al que se encuentra por defecto.
- Finalmente acepte los cambios realizados y compruebe en su lista que el cambio haya sido realizado.
More Posts
Next page »