El blog de Lluis Franco : Windows

Windows Server 2008 R2 RTM (y también Windows 7!)

lfranco — Thu, 23 Jul 2009 09:13:00 GMT

Acabo de leer en el blog del equipo de Windows Server que hoy la R2 del 2008 ha alcanzado el estado RTM (Release to Manufacturing), de modo que el producto ya está listo par enviar a fábrica. Se espera que en unos días esté disponible para partners en MSDN y TechNet, posteriormente para Partners y finalmente para el gran público:

Las fechas son:

MSDN/Technet: W7 Aug 6, R2 Aug 14
Partner Network: W7 Aug 16, R2 Aug 19
Action Pack: Aug 23 (W7 & R2)
Volume Licensing (SA): W7 Aug 7, R2 Aug 19

Tengo muchas ganas de probar las nuevas capacidades de virtualización, espero poder escribir sobre ellas en los días siguientes a su publicación, siempre que el project se respete y pueda dedicarme un poco a I+D, que últimamente no me han dado demasiado tiempo.

Os dejo con el artículo original:

Wednesday, July 22, 2009 6:40 AM WindowsServer

Windows Server 2008 R2 Reaches the RTM Milestone!

The acronym stands for Release to Manufacturing, and it means this latest release of Windows Server 2008 R2 is now blessed by engineering as ready for the manufacturing process. We're talking final code. Sun shining, birds singing, children dancing in the streets.

With evaluation software available for download in the first half of August and the full product available to customers with Software Assurance in the second half of August, RTM is more than just an engineering milestone. Occurring in lock-step with the release of the Windows 7 RTM, these two platforms are now ready for our partners to start testing and installing on their hardware. And that lock-step isn't a coincidence, it's a design goal.

Customers using Windows Server 2008 R2 and Windows 7 in their enterprises has been Microsoft's intent from the first day programmers touched fingers to keyboards. Let's look at the highlights:

HAPPY ADMINISTRATORS

It's Christmas for server and desktop administrators with Windows Server 2008 R2's updated management tools, including:

Hyper-V and Live Migration - still the big stars. R2's Hyper-V enables a complete server virtualization solution available out-of-the-box. Live Migration allows server administrators to migrate VMs between physical machines with no perceived downtime for current server connections and work streams. That means a more dynamic datacenter and more agility in meeting new business needs For more information on Hyper-V in R2, check out today's in-depth post on the Virtualization Team blog.
File Classification Infrastructure - FCI lets you manage your data based on its characteristics, including things like file type, user credentials and even content. Based on this kind of criteria, FCI can assign data different access restrictions, store it in different locations or simply push it into an entirely customized lifecycle scheme - all done automatically via policy. For me, this is one of the most exciting new features in R2.
Active Directory and Pervasive PowerShell - 240 new PowerShell cmdlets and several management consoles (including a new Active Directory interface) have been built on top of PowerShell. Active Directory has also been enhanced with the Active Directory Recycle Bin as well as AD Group Policy objects that give desktop administrators deeper capabilities when it comes to managing Windows 7 clients.
IIS 7.5 - The latest edition of Internet Information Server also sports updated management tools as well as application serving capabilities that now including support for PHP and .NET on Server Core installations.
Server Scalability - Not only is R2 Microsoft's first 64-bit-only operating system, it also supports up to 256 logical processors in a single server as well as all the latest CPU technologies. And, R2 has support for advanced storage technologies, including SAN management and solid state hardware.

HAPPY USERS

I'll leave it to the Windows 7 team to evangelize the many advantages that Windows 7 has as a standalone operating system (click here for the Windows 7 RTM announcement). But we server guys love it because combined with Windows Server 2008 R2 we can provide features I've never seen before in another client-server platform.

DirectAccess, for example, provides secure, always-on access to corporate networks no matter from what network a client might be connecting. Better yet, it provides a two-way relationship allowing desktop admins to manage clients the same way whether they're local or remote.
BranchCache allows users in remote offices to cache corpnet data locally, providing a better work experience for remote workers while simultaneously lowering expensive WAN bandwidth costs.
Remote Desktop and Applications - Windows Server 2008's Terminal Services has now evolved into R2's Remote Desktop Services, and it integrates so tightly with Windows 7 that administrators will be able to roll out virtualized applications and even entire desktop environments without users being able to tell that these tools aren't running locally. It's fast and can even be managed via policy. Very cool stuff.

LOWER BUDGETS

Power efficiency and power management were priorities for R2. The power efficiency improvements help you save power automatically - without additional steps or configuration. An improved processor power management engine, storage power management improvements, tick skipping, core parking, and timer coalescing all contribute to improved power efficiency.

While licensing topics are a bit arcane, those of you already running Windows Server 2008 should know that you don't need new Client Access Licenses (CALs) when updating to Windows Server 2008 R2, which helps make for a cost-effective upgrade.

I'm out of space and have only scratched the surface of what you'll find in R2. You can follow the buzz about R2 and Windows 7 on Twitter via the #Windows hashtag.

For those evaluating the software for near-term deployment, make sure to visit the Windows Server 2008 R2 Resource Center, our TechNet Resource Center as well and also our Application Compatibility page. And as always, send us your feedback when you're testing the software. Happy testing,

--Oliver Rist

Technical Product Manager

** crossposting desde el blog de Lluís Franco en geeks.ms **

J*der que susto!

lfranco — Fri, 06 Feb 2009 19:57:00 GMT

Viernes por la tarde, toda la oficina para nosotros.

Hoy tenemos planificada la actualización del domino principal 2003 a 2003 R2, algo trivial y que en teoría no debe llevarnos demasiado tiempo. De hecho no sería necesario que nos quedásemos más de uno pero hemos pensado en acabar pronto con esto e ir todos a tomar una cerveza :-P

Vamos al lío.

Procedemos a actualizar el esquema con el conocido adprep /forestprep y a continuación vamos a lanzar el asistente de instalación de Windows Server 2003 R2, cuando de pronto aparece un mensaje de error que nos impide continuar:

Otra aplicacion requiere que este equipo se reinicie. Bla, bla, bla...

Uhm... vaya, esto no debería pasar pero bueno, por si acaso vamos a reiniciar y volvemos a probar. Reiniciamos el equipo (menos mal que a esta hora ya no hay nadie trabajando, probamos otra vez y... lo mismo. Ups! Volvemos a reiniciar otra vez mientras se forman las primeras gotas de sudor y nada. Otra vez lo mismo.

Uy, uy, uy...

...

Mierda.

El pánico empieza a apoderarse de nosotros mientras empiezo a pensar que este mensaje ya lo he visto con anterioridad, aunque sin embargo no apareció en las pruebas de pre-producción. Intento recordar cuándo vi este mensaje y cómo lo resolví, pero no me acuerdo :-S

De pronto tengo una inspiración divina: Creo que ya se que pasa, y busco en en la kb de http://support.microsoft.com/ por incidencias con Microsoft Windows Installer. Afortunadamente no pasan ni dos minutos y ya he encontrado una entrada que tiene muy buena pinta.

El problema es que Microsoft Windows Installer determina que la entrada de registro PendingFileRenameOperations no está vacía, con lo que antes de iniciar cualquier instalación hay que revisar y limpiar (o renombrar) esta clave de registro.

Abro el registro, busco la clave y “oh sorpresa! oh dolor! oh campos de soledad, mustios collados...”, un fichero de la instalación del anvitirus. Pues nada, a la hoguera con él :-)

La solución consiste en:

Cambiar manualmente el nombre de la entrada de registro PendingFileRenameOperations. Para ello, siga estos pasos:
1. Haga clic en inicio y, a continuación, haga clic en Ejecutar .
2. En el cuadro Abrir , escriba regedit y, a continuación, haga clic en ACEPTAR para iniciar el Editor del registro.
3. En el Editor de Registro, busque y haga clic en la siguiente subclave del registro:
  
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
4. En el nombre en el panel derecho del editor del registro, cambiar el nombre del PendingFileRenameOperations entrada del registro.
Compruebe que la siguiente subclave del registro está vacía:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Compruebe que la siguiente subclave del registro está vacía:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
Cierre el Editor del Registro y ejecutar de nuevo el programa de instalación (en nuestro caso Windows 2003 R2).

Diez minutos después ya hemos terminado y ahora escribo esta entrada por si a alguien le sucede lo mismo. Aunque el susto se lo llevará igual :-)

Saludos y buen fin de semana,

** crossposting desde el blog de Lluís Franco en geeks.ms **

The Bumper List of Windows 7 Secrets

lfranco — Wed, 14 Jan 2009 03:07:00 GMT

Gracias al gran Juls, acabo de leer un excelente artículo sobre Windows 7. Es de lectura imprescindible para todos aquellos que esteis ‘trasteando’ con el nuevo Windows 7. En él se explican 30 funcionalidades que van a hacer las delicias de más de uno.

Podeis encontrar el artículo en esta dirección:
http://blogs.msdn.com/tims/archive/2009/01/12/the-bumper-list-of-windows-7-secrets.aspx

Y ahora una pregunta: Cuál de ellos de os ha gustado más?

Espero vuestras respuestas,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Folder size: Primer contacto

lfranco — Fri, 08 Aug 2008 12:09:51 GMT

Harto de buscar dónde se iba el espacio de mi disco duro, y con la sensación de que estaba malgastando un porrón de bytes (y os aseguro que no es en peliXculas), me puse a diseñar una herramienta que me mostrase lo que ocupa cada una de las carpetas de mi ordenador. De esto hace un par de días, y la verdad es que me he liado la manta a la cabeza :-P y al final el resultado es este:

Está enteramente escrito en C# 3.0 y aunque el funcionamiento es más sencillo que el mecanismo de un botijo (al fin y al cabo sólo recorre una estructura de carpetas y va procesando archivos), el resultado me gusta. Para compensar su sencillez le he añadido una interfaz cool (al menos para mí :-P), multithreading en la búsqueda, que a su vez hace uso de llamadas al FindFirstFile y FindNextFile para mejorar la performance... Aunque seguro que mi amigo el rano, belmonte de pro, me dice que si quiero ver performance me deje de tonterías y vuelva al C++ duro. Y os juro y perjuro que ya no me acuerdo de cómo se cocinaba con punteros. Además el resultado puede imprimirse o también exportar a Excel o PDF, y también muestra una lista de posibles errores producidos durante el análisis de la(s) carpeta(s), que mayormente son de acceso a ciertos elementos de sistema (o ubicaciones de red con permisos NTFS).

Si a alguien le apetece probarlo os lo podéis instalar desde esta ubicación:

http://utilities.ordeeno.com/foldersize/

El único requisito es el Framework 3.5, y si no lo tenéis instalado el programa de instalación muy amablemente lo hará por vosotros (eso si, tarda un ratito).

La licencia es beerware, lo cual quiere decir que si te gusta y lo usas... deberás invitarme al menos a una cerveza. Y si es con papas, mejor que mejor!

Bye @ home,

PD - Lo he probado en XP y Vista Ultimate y de momento no le he encontrado ningún bug grave, pero si vosotros lo hacéis podéis contactar conmigo aquí.

** crossposting desde el blog de Lluís Franco en geeks.ms **

Corrección función getUserLDAPProperties

lfranco — Thu, 10 Jul 2008 09:01:18 GMT

Corrección aplicable al post:

http://geeks.ms/blogs/lfranco/archive/2008/07/08/accediendo-al-directorio-activo-de-la-organizaci-243-n-desde-net-iv.aspx

Ayer estuve revisando una de las funciones de la librería LDAPservices, que se encarga de devolver los nombres de las propiedades del objeto usuario dentro del AD. Hoy os publico una corrección, ya que observé que la función no devolvía correctamente todos los nombres de propiedades.

Este bug es producido porque en la función se utiliza un objeto DirectorySearcher para devolver todos los objetos de tipo usuario en el AD, a continuación lee los nombres de las propiedades del primer usuario encontrado y los inserta en una colección. A continuación la función no continúa procesando el resto de usuarios, ya que deberían tener las mismas propiedades, no? Pues no. Para mi sorpresa resulta que sólo se devuelven aquellas propiedades del usuario que han sido informadas:

public static List<string>

    getUserLDAPProperties(string LDAPURL)

    List<string> properties =new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, "(&(objectCategory=person)(objectClass=user))");

try

        foreach (SearchResult result in searcher.FindAll())

            foreach (string property in

                result.GetDirectoryEntry().Properties.PropertyNames)

                properties.Add(property);

            break;

    catch (Exception ex)

        throw ex;

    return properties;

Para solucionar este bug, hay que procesar las propiedades de todos los usuarios, quedando el código de la función así como sigue:

foreach (SearchResult result in searcher.FindAll())

    foreach (string property in

        result.GetDirectoryEntry().Properties.PropertyNames)

        if(!properties.Contains(property)) properties.Add(property);

Como veis, se suprime el break que terminaba el bucle y se añade una condición para que se agreguen a la colección sólo aquellos nombres de propiedad que no se han agregado previamente.

Saludos y happy coding!!!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (IV)

lfranco — Tue, 08 Jul 2008 12:27:24 GMT

Buscar

Hoy vamos a buscar. Buscar elementos en el AD dentro de nuestra organización, y como lo más habitual es buscar usuarios o grupos he creado algunas funciones para facilitar esta tarea dentro de la clase LDAPServices (os dejo para vosotros ampliarlas para buscar equipos, por ejemplo).

También veremos cómo extraer los nombres de las propiedades de un objetos del AD, ya que en ocasiones queremos filtrar o devolver el valor de una propiedad de un objeto y no sabemos cómo se llama esta propiedad. Por ejemplo, para devolver el teléfono de un usuario en el AD hay que preguntar por el valor de la propiedad 'telephoneNumber'.

Tal vez más adelante (si tengo tiempo) lo ampliemos un poco. Me gustaría realizar un post acerca de cómo realizar un mapeador de propiedades para asignar los valores de las propiedades de objetos LDAP a objetos de nuestra aplicación. Esto podría ser muy útil por ejemplo, para importar los valores de nuestros usuarios de AD a una tabla de empleados.

Antes de empezar quiero comentaros que para poder realizar todo esto va a ser necesario agregar una referencia a System.DirectoryServices a nuestro proyecto. Pero vamos ya con estos nuevos métodos de LDAPServices:

getLDAPFilterString - Devuelve una cadena de consulta en formato LDAP query, que permite filtrar los objetos que deseamos devolver. Esta función filtra aquellos carácteres no deseados para evitar posible inyección de código LDAP por parte de un usuario (aunque es muy mejorable, estoy seguro que mi JoseMariCariño sería capaz de sacar información de aquí, casi me apuesto algo).

public enum LDAPFilterType

    UsersAndGroups,

    OnlyUsers,

    OnlyGroups

public static string

    getLDAPFilterString(LDAPFilterType Type, string Filter)

    Filter = Filter.Replace("&","");

    Filter = Filter.Replace("|","");

    Filter = Filter.Replace("*", "");

    string FilterByName = "(samAccountName=*{0}*)";

    string f = string.Empty;

    switch (Type)

        case LDAPFilterType.OnlyUsers:

            f = "(&(objectCategory=person)(objectClass=user){0})";

            break;

        case LDAPFilterType.OnlyGroups:

            f = "(&(objectCategory=Group){0})";

            break;

        case LDAPFilterType.UsersAndGroups:

            f = "(|(&(objectCategory=person)(objectClass=user){0})(&(objectCategory=Group){0}))";

            break;

    if (Filter == string.Empty)

        return string.Format(f, string.Empty);

    else

        return string.Format(f, string.Format(FilterByName, Filter));

getItemsInLDAP - Basándose en el método anterior, realiza la consulta al AD y devuelve una lista con los objetos coincidentes. Su funcionamiento se basa en un objeto DirectoryEntry, que apunta al AD que se le ha pasado como aergumento. Y en un objeto DirectorySearcher, que es el que realmente se encarga de buscar las entradas coincidentes con el filtro en el DirectoryEntry.

public static List<string>

    getItemsInLDAP(string LDAPURL, LDAPFilterType type, string criteria)

    List<string> items = new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    string filter = getLDAPFilterString(type, criteria);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, filter);

try

        foreach (SearchResult result in searcher.FindAll())

            items.Add((string)result.Properties["samAccountName"][0]);

    catch (Exception ex)

        throw ex;

    return items;

Para probar esta funcionalidad basta con tener un TextBox en el que introducir el criterio de búsqueda y un ComboBox en el que especificar que objetos deseamos buscar. Así cómo un CommandButon para lanzar la consulta y un ListBox en el que mostrar los resultados:

El código es muy sencillo. Basta con asignar el valor devuelto por la función getItemsInLDAP al DataSource de la lista.

private void cmbSearch_Click(object sender, EventArgs e)

try

        string dcName = LDAPServices.getLDAPDomainName(txtDomain.Text);

        List<string> items = LDAPServices.getItemsInLDAP(dcName,

            (LDAPServices.LDAPFilterType) cmbType.SelectedIndex, txtCriteria.Text);

        lstItems.DataSource = items;

    catch (Exception ex)

        MessageBox.Show(ex.Message,

             Application.ProductName,

             MessageBoxButtons.OK,

             MessageBoxIcon.Exclamation);

getUserLDAPProperties - Devuelve una lista de cadenas con los nombres de las propiedades de un objeto User dentro del AD. Cabe observar que el esquema del AD es variable, con lo que las propiedades devueltas pueden cambiar. Por ejemplo, productos que se integran fuertemente con AD como Exchange agregan propiedades a los objetos usuario y grupo.

public static List<string>

    getUserLDAPProperties(string LDAPURL)

    List<string> properties =new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, "(&(objectCategory=person)(objectClass=user))");

try

        foreach (SearchResult result in searcher.FindAll())

            foreach (string property in

                result.GetDirectoryEntry().Properties.PropertyNames)

                properties.Add(property);

            break;

    catch (Exception ex)

        throw ex;

    return properties;

De este modo podemos saber las propiedades de un objeto dentro de nuestro AD. Esto es más importante de lo que parece, ya que cuando buscamos elementos dentro del AD, no se devuelven todas las propiedades de forma predeterminada. Para agregar el valor de una propiedad a los resultados de la búsqueda ésta debe añadirse explícitamente mediante la colección PropertiesToLoad:

searcher.PropertiesToLoad.Add("telephoneNumber");

Y luego comprobar si existe valor devuelto, ya que es posible que no exista o no devuelva valor:

if (r.Properties("telephoneNumber").Count > 0)

//

Y hasta aquí el cuarto capítulo de esta serie. Espero que os sea útil, recordar que en esta ocasión el código completo lo publiqué en el post anterior.

Nos vemos pronto!
Un saludo desde Andorra,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (III)

lfranco — Fri, 04 Jul 2008 15:45:18 GMT

En vista a que bastante gente me ha pedido si puedo publicar ya el código del proyecto de ejemplo, he decidido publicarlo ahora en lugar de esperar al último post de la serie. En caso que se realicen variaciones en el código, las publicaré posteriormente.

Aquí lo teneis, publicado en skydrive (*):

(*) En ocasiones, al realizar cross-posting a otros blogs desde el original de geeks.ms, tal vez no aparezca correctamente el enlace a skydrive. Si es así, os recomiendo que visitéis el post original en geeks.ms y realicéis la descarga desde éste.

En el post anterior, os dije que en el siguiente (este post) mostraríamos cómo realizar la suplantación (Impersonate) de usuario de Windows para ejecutar nuestra aplicación con otras credenciales. Sin embargo, como ésto ya lo mostré en otro post de una serie anterior, lo doy por explicado y así avanzamos un poco más.

System.Net.NetworkInformation

Antes de entrar al trapo, un pequeño apunte. Apuntaros este espacio de nombres, que hemos utilizado para obtener algunos datos básicos para el proyecto, y que contiene un montón de métodos que devuelven información muy interesante sobre el tráfico y estadísticas de red.

LDAPServices

Vamos a ir comentando algunas de los métodos que proporciona esta clase. Como os comenté son todos estáticos, por lo que no es necesario instanciar un objeto para invocarlos. Empecemos:

sIDtoString - Trabajando con el AD constantemente vamos a encontrarnos con los llamados SID (identificadores de seguridad). Este método se encarga de transformar un SID (array de bytes) en una cadena de texto que pueda ser mostrada al usuario.

public static string

    sIDtoString(byte[] sidBinary)

    SecurityIdentifier sid = new SecurityIdentifier(sidBinary, 0);

    return sid.ToString();

getNTAccountName - Devuelve el nombre del objeto dentro del AD a partir de su SID. Por ejemplo, a partir de un identificador de seguridad como {S-1-5-12-7623811015-3361044348-030300820-1013} retorna un string con formato: 'DOMINIO\NombreObjeto'.

public static string

    getNTAccountName(string wksid)

    SecurityIdentifier sid = new SecurityIdentifier(wksid);

    NTAccount account = (NTAccount)sid.Translate(typeof(NTAccount));

    return account.Value;

getADUserMemberOf - Devuelve un diccionario con los grupos a los que pertenece un usuario. Espera un argumento de tipo token de seguridad (habitualmente utilizaremos el WindowsIdentity.GetCurrent().Token) y el diccionario genérico devuelto es de tipo <string, IdentityReference>.

public static Dictionary<string, IdentityReference>

    getADUserMemberOf(IntPtr logonToken)

    Dictionary<string, IdentityReference> groups =

        new Dictionary<string, IdentityReference>();

    WindowsIdentity user = new WindowsIdentity(logonToken);

    IdentityReferenceCollection irc = user.Groups;

    foreach (IdentityReference ir in irc)

        groups.Add(getNTAccountName(ir.Value), ir);

    return groups;

(*) Al ir escribiendo el artículo me he dado cuenta de que esta función podría ser optimizada, aprovechando algunas de las nuevas características de C# 3.0, incorporadas en Visual Studio 2008. De modo que podría ser re-escrita del siguiente modo ¡en tan sólo 3 líneas!

public static Dictionary<string, IdentityReference>

    getADUserMemberOf2(IntPtr logonToken)

    WindowsIdentity user = new WindowsIdentity(logonToken);

    var groups = from g in user.Groups select g;

    return groups.ToDictionary(p => getNTAccountName(p.Value));

¿Menudo cambio, verdad? Observar el uso de:

Inferencia de tipos (var)
Palabras clave de consulta (from, in, select)
Expresiones lambda en la llamada al método extensor ToDictionary (p => getNTAccountName(p.Value))

La verdad es que en cuanto empiezas a usar estas mejoras te 'enganchan'. No sabeis la cara de bobo que se me queda cuando a veces abro el editor de VB6.0 (si, habéis oído bien) para realizar alguna modificación en aplicaciones que todavía no se han migrado a .NET (y lo que les queda... :-P).

Hasta aquí algunos de los métodos que contiene la clase LDAPServices. En el próximo post veremos cómo obtener la lista de propiedades de un objeto user dentro del directorio activo, así cómo realizar búsquedas de objetos dentro del directorio.

No vemos pronto,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (I)

lfranco — Wed, 11 Jun 2008 18:16:35 GMT

Creo que me estoy aficionando a las series ~~de posts no de la tele~~, ya que acabo de terminar la serie de artículos acerca de cómo acceder a la caché de Internet Explorer y ya estoy planteándome una nueva, sobre acceder al directorio activo mediante una aplicación realizada con C#. Esta serie, al igual que la anterior intentará ser lo más directa y práctica posible, y del mismo modo al final de la serie publicaré el código completo del ejemplo para su descarga.

El motivo...

...de esta serie es porque tanto en los foros como en los grupos de notícias, es muy común encontrar preguntas muy variadas acerca de cómo acceder a LDAP desde una aplicación .NET. Así que me he planteado empezar una serie de posts en los que mostraremos varios ejemplos: Mostrar información del usuario actual de Windows, averiguar los grupos a los que pertenece, validar credenciales contra un dominio para saber si son correctas, impersonar nuestra aplicación para que se ejecute con las credenciales de otro usuario, buscar usuarios o grupos en LDAP, extraer la lista de propiedades del objeto usuario, etc.

¿LDAP o Directorio Activo?

Antes de empezar quiero hacer una aclaración: ¿Es lo mismo LDAP que Directorio Activo? No, no es lo mismo.

LDAP es el acrónimo de (Lightweight Directory Access Protocol) que es es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. Habitualmente se utiliza para acceder a la información almacenada de usuarios, grupos y equipos de una organizació y existen muchas implementaciones de este protocolo, desde Microsoft hasta Novell pasando por Red Hat, iPlanet u OpenLDAP.

El directorio Activo o AD es la implementación de LDAP realizada por Microsoft en su família Windows Server. Al igual que LDAP permite acceder a distintos tipos de objetos almacenados que representan los elementos de la organización. Cada uno de estos objetos tendrá atributos que permiten identificarlos en modo unívoco (por ejemplo, los usuarios tendrán campo "nombre", campo "email", etc..., las impresoras de red tendrán campo "nombre", campo "fabricante", campo "modelo", campo "usuarios que pueden acceder", etc). Toda esta información queda almacenada en Active Directory replicándose de forma automática entre todos los servidores que controlan el acceso al dominio.

Situaciones cotidianas

Nosotros los desarrolladores, como creadores de aplicaciones que deben coexistir en un entorno corporativo, cada vez nos encontramos en más ocasiones en las que nuestra aplicación debe utilizar los usuarios y grupos del AD de la empresa, en lugar de almacenar una base de datos propia de usuarios y grupos. Incluso me atrevería a decir que la frontera entre una aplicación madura, de uso corporativo, y que se integre con otras aplicaciones y servicios, a veces estriba en detalles como éste.

Hoy en día cada vez más empresas disponen de la figura del administrador del AD, que gestiona todos los datos de los empleados de la misma, de modo que ¿para que van a mantener otra base de datos con los usuarios de una aplicación, si éstos ya existen en el AD? Incluso puede ser peor ¿os imagináis cuántas aplicaciones funcionan de este modo? ¿Debemos mantener X bases de datos de usuarios por X aplicaciones? Esto puede ser el caos... ¡imaginaos la de datos duplicados que existen y lo difícil que resulta mantenerlos!

Gracias al .NET framework, hoy en día podemos integrar nuestras aplicaciones con el AD de la empresa, de forma que podamos aprovechar la ventaja de contar con un repositorio centralizado. De este modo podremos dejar en manos del administrador del AD la creación de usuarios, grupos y cómo se relacionan entre ellos, y nosotros encargarnos de lo que realimente nos importa: La aplicación.

En el próximo post empezaremos a construir nuestra aplicación de ejemplo, y para ello contaremos con la ayuda del namespace System.Security.Principal y de System.DirectoryServices... hasta entonces!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Acceder a la caché de Internet Explorer (V y final)

lfranco — Tue, 10 Jun 2008 14:12:31 GMT

Éste es el último post de esta serie, en la cual se ha desarrollado un proyecto de ejemplo de cómo acceder a la caché de archivos temporales de Internet Explorer. De hecho, he aprovechado la excusa para montar un pequeño proyecto de ejemplo en el que poder enseñar varias cosas que tenía en mente y por falta de tiempo no podía postear.

ASí pues en éste ejercicio hemos mostrado entre otras cosas cómo:

Utilizar el API para acceder a los archivos temporales de Internet (post 1)
Persistir objetos .NET en ficheros XML mediante serialización (post 2)
Impersonar, para ejecutar temporalmente muestra aplicación con las credenciales de otro usuario (post 3)
Crear y distribuir nuestra aplicación como un servicio de Windows (post 4)

Y aquí os dejo el código completo del ejemplo:

Espero que os guste,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Acceder a la caché de Internet Explorer (IV)

lfranco — Fri, 30 May 2008 16:22:52 GMT

En los dos primeros artículos pudimos ver los objetos del API de Windows que íbamos a usar para poder acceder a la caché de los archivos temporales de Internet, cómo persistir estos datos en formato XML, y finalmente cómo permitir que temporalmente nuestra aplicacación se ejecute con las credenciales de otro usuario, para poder realizar una serie de acciones que de otro modo no podría efectuar por falta de privilegios.

Siguiendo con el objetivo de este ejercicio hoy vamos a encapsular la lógica de negocio de nuestra aplicación en forma de servicio de Windows, y éste va a encargarse de realizar una consulta a la caché de Internet de nuestro ordenador cada X tiempo (configurable mediante un fichero XML).

Lo primero de todo va a ser construir la base de nuestro servicio mediante un proyecto de tipo Windows Service. Esta plantilla nos genera un proyecto con un componente de tipo ServiceBase, que servirá para ir construyendo nuestro pequeño juguetito.

A continuación vamos a cambiar el nombre al servicio, en nuestro caso lo llamaremos "IECacheQueryService". Y posteriormente estableceremos a True los valores de las propiedades CanPauseAndContinue y CanShutdown, para poder pausar y detener nuestro servicio en tiempo de ejecución.

Importante: Comprobar que el nombre sel servicio se ha cambiado correctamente en el punto de entrada de la aplicación (si no fuese así tendremos que modificarlo manualmente):

static class Program

        static void Main()

            ServiceBase[] ServicesToRun;

            ServicesToRun = new ServiceBase[]

                new IECacheQueryService()

};

            ServiceBase.Run(ServicesToRun);

Implementando funcionalidad al servicio:

De momento el servicio será capaz de iniciarse, pero no realizará nada. Ahora debemos dotarlo de funcionalidad, y para ello vamos a crear un temporizador que se encargue de realizar una tarea cada X tiempo (por defecto una hora). Éste lo crearemos como un miembro dentro de nuestra clase:

public partial class IECacheQueryService : ServiceBase

    private Timer clock = new Timer();

Y lo usaremos desde el constructor de la misma, así como en los eventos OnStart y OnStop. Observar que en el constructor lo inicializamos con un valor que proviene del fichero de configuración del proyecto (propiedades del proyecto/settings) llamado TimerInterval y se ha establecido a un valor de 3.600.000 (1 hora en milisegundos).

public IECacheQueryService()

    InitializeComponent();

    clock = new Timer(Properties.Settings.Default.TimerInterval);

    clock.Elapsed += new ElapsedEventHandler(clock_Elapsed);

    clock.Enabled = true;

    //...

protected override void OnStart(string[] args)

    ExecuteQuery();

    clock.Start();

    //...

protected override void OnStop()

    clock.Stop();

Del mismo modo también especificamos el manejador de evento asociado que se ejecutará cada vez que se cumpla este intervalo de tiempo (clock_Elapsed). Éste será el corazón de nuestro servicio y será el encargado de invocar la consulta a la caché de IE:

void clock_Elapsed(object sender, ElapsedEventArgs e)

try

            ExecuteQuery();

        catch (Exception ex)

            appEventLog.WriteEntry("Exception: " + ex.Message,

                EventLogEntryType.Error);

Simple verdad? Ahora vamos a construir este método ExecuteQuery a apartir de las piezas que vimos en anteriores entradas de la misma serie. No os preocupeis que en el último post estará un enlace al código completo del ejemplo (incluido el instalable).

Que hace exactamente este método?

Primero de todo crea un objeto de tipo StopWatch para medir con precisión el tiempo que transcurre en la ejecución del mismo.
Llama al método getResults que se encarga de efectuar la consulta y devolver un objeto que es una lista genérica de entradas de la caché.
Construye el nombre de fichero en el que guardaremos los resultados y llama al método saveResults, encargado de realizar la suplantación de identidad y serializar los resultados en el fichero antes mencionado.

private void ExecuteQuery()

try

        Stopwatch watch = new Stopwatch();

        watch.Start();

        List<IECacheEntry> results = getResults(

            Properties.Settings.Default.SearchPattern);

        string filename = string.Format("{0}{1}_{2}.xml",

            Properties.Settings.Default.TargetPathLocation,

            Environment.MachineName,

            DateTime.Now.ToString("ddMMyyyy_hhmm"));

        watch.Stop();

        TimeSpan ts = watch.Elapsed;

        saveResults(results, filename);

        appEventLog.WriteEntry(string.Format(

            "Query executed successfully at {0} in '{1}' by user '{2}'. Elapsed time (ms): {3}",

            DateTime.Now.ToString(), Environment.MachineName,

            WindowsIdentity.GetCurrent().Name,ts.Milliseconds));

    catch (Exception ex)

        appEventLog.WriteEntry("Exception: " + ex.Message,

            EventLogEntryType.Error);

Está el servicio terminado? Bueno, si asumimos que el código está completo y funciona sin errores, sí, lo está :-P

Y ahora cómo lo probamos? Pues... bueno, para probarlo antes tenemos que instalarlo.

Agregando los elementos necesarios para instalar el servicio:

No he encontrado demasiada documentación al respecto, de modo que intentaré mostrar los pasos a seguir mediante capturas de pantalla.

Vamos a agregar un elemento que nos permita distribuir el servicio:

Le agregaremos dos componentes serviceProcessInstaller y serviceInstaller (es posible que no aparezcan en la barra de herramientas, así que tendremos que agregarlos mediante la opción "Choose Items..."

A continuación los configuraremos del siguiente modo:

Control	Propiedad	Valor
serviceProcessInstaller1	Account	LocalSystem (*)
serviceProcessInstaller1	Parent	Installer1
serviceInstaller1	Description	Internet Explorer Query Cache
serviceInstaller1	Display Name	Internet Explorer Query Cache
serviceInstaller1	Parent	Installer1
serviceInstaller1	ServiceName	IEQueryCache
serviceInstaller1	StartType	Automatic

(*) Habitualmente se utilizará siempre la cuenta con menos nivel de privilegios (LocalService), pero en nuestro caso necesitamos acceder a la caché de IE, de modo que es posible que incluso tengamos que configurar la cuenta de un usuario de windows con suficientes permisos.

Cruzamos los dedos, compilamos el proyecto y vamos a agegar un proyecto de instalación a la solución.

Creando el proyecto de instalación:

Agregaremos un proyecto de tipo Setup and deployment, que será el encargado de instalar nuestro servicio en las estaciones Windows que deseamos monitorizar.

Agregamos la salida del proyecto anterior al nuevo proyecto de instalación:

Ahora mostraremos la ventana de "custom actions" para agregar como acción al instalador la salida de nuestro proyecto de servicio de Windows.

Una vez realizado esto ya podemos compilar el proyecto de instalación e instalarlo en las estaciones cliente. Si quereis instalarlo en vuestra estación para probarlo y configurarlo adecuadamente, la opción más sencilla es seleccionar la opción Install del menú contextual del proyecto de instalación, en el explorador de proyectos.

Una vez instalado, aparecerá en el administrador de servicios, para que podamos configurarlo del modo deseado. En este caso particular, si deseamos monitorizar la caché de un usuario en particular, deberemos usar las credenciales de éste usuario, ya que si no el S.O. no será capaz de montar el fichero Index.dat correspondiente a la caché de Internet Explorer.

Bueno, hasta aquí ha llegado este ejemplo. En el próximo post haremos un resumen de lo que se ha visto hasta ahora y publicaré un enlace con el código completo del proyecto para que sirva de ejemplo (o de mal ejemplo :-P).

Saludos desde andorra,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Acceder a la caché de Internet Explorer (III)

lfranco — Mon, 26 May 2008 15:04:01 GMT

Impersonation => RunAs

En los dos primeros artículos pudimos ver los objetos del API de Windows que íbamos a usar para poder acceder a la caché de los archivos temporales de Internet, y como persistir estos datos en formato XML.

Hoy vamos a usar Impersonation para ejecutar nuestra aplicación con otras credenciales de usuario, de este modo nos conectaremos a una ubicación remota a la cual sólo tienen permisos para conectarse los administradores.

Supongamos que tenemos una ubicación similar a esta: \\RootDFS\Logs\IECacheQuery\ y que sólo los usuarios del grupo administradores pueden acceder a leer y modificar su contenido. Si nuestra aplicación se ejecuta con permisos del usuario o servicio local, no podremos guardar los archivos de registro. Sin embargo, en un momento dado nuestra aplicación puede elevar su nivel de privilegios usando las credenciales del administrador, ejecutar las tareas requeridas, y posteriormente volver a su nivel predeterminado para continuar con su ejecución como si tal cosa.

A este proceso se le llama impersonar o suplantar, aunque personalmente no me gusta demasiado la traducción por las posibles connotaciones negativas que conlleva. Y básicamente se trata de que durante un lapso de tiempo nuestra aplicación va a estar ejecutándose con un usuario distinto al usuario que ha iniciado la aplicación.

Artistas invitados: LogonUser y DuplicateToken

La primera de ellas verifica si las credenciales suministradas son correctas, validándolas contra un dominio (que puede ser la estación local) y devuelve un token, mientras que la segunda crea una copia de un token existente. Hay que mencionar un detalle importante y es que el token devuelto por DuplicateToken es lo que se llama un 'impersonation token', que no es válido para la función CreateProcessAsUser ya que ésta necesita un token primario. Si deseamos usar ésta función debemos usar como alternativa la función DuplicateTokenEx.

[DllImport("advapi32.dll", SetLastError = true)]

public static extern bool LogonUser(string pszUsername, string pszDomain, string pszPassword,

    int dwLogonType, int dwLogonProvider, ref IntPtr phToken);

[DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)]

public extern static bool DuplicateToken(IntPtr ExistingTokenHandle,

    int SECURITY_IMPERSONATION_LEVEL, ref IntPtr DuplicateTokenHandle);

Más información aquí:

LogonUser Function:

http://msdn.microsoft.com/en-us/library/aa378184(VS.85).aspx

DuplicateToken Function:
http://msdn.microsoft.com/en-us/library/aa446616(VS.85).aspx

Bien, ahora que ya nos conocemos todos vamos a ver un fragmento del código de la aplicación, que usa estas funciones para impersonar un usuario y devolver un objeto de tipo WindowsImpersonationContext. Posteriormente podremos usar el método 'Undo' de este objeto para deshacer el contexto de suplantación y volver al contexto anterior, de forma que la aplicación seguirá ejecutándose con el usuario que la ha lanzado.

public WindowsImpersonationContext ImpersonateUser(

    string sUsername, string sDomain, string sPassword)

    IntPtr pExistingTokenHandle = new IntPtr(0);

    IntPtr pDuplicateTokenHandle = new IntPtr(0);

    pExistingTokenHandle = IntPtr.Zero;

    pDuplicateTokenHandle = IntPtr.Zero;

    if (sDomain == "") sDomain = System.Environment.MachineName;

try

        string sResult = null;

        const int LOGON32_PROVIDER_DEFAULT = 0;

        const int LOGON32_LOGON_INTERACTIVE = 2;

        bool bImpersonated = LogonUser(sUsername, sDomain, sPassword,

            LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,

            ref pExistingTokenHandle);

        if (false == bImpersonated)

            int nErrorCode = Marshal.GetLastWin32Error();

            sResult = "LogonUser() failed with error code: " + nErrorCode + "\r\n";

            throw new Exception(sResult);

        sResult += "Before impersonation: " + WindowsIdentity.GetCurrent().Name + "\r\n";

        bool bRetVal = DuplicateToken(pExistingTokenHandle,

            (int)SECURITY_IMPERSONATION_LEVEL.SecurityImpersonation,

            ref pDuplicateTokenHandle);

        if (false == bRetVal)

            int nErrorCode = Marshal.GetLastWin32Error();

            CloseHandle(pExistingTokenHandle);

            sResult += "DuplicateToken() failed with error code: " + nErrorCode + "\r\n";

            throw new Exception(sResult);

            return null;

        else

            WindowsIdentity newId = new WindowsIdentity(pDuplicateTokenHandle);

            WindowsImpersonationContext impersonatedUser = newId.Impersonate();

            sResult += "After impersonation: " +

                WindowsIdentity.GetCurrent().Name + "\r\n";

            this.ImpersonationContext = impersonatedUser;

            return impersonatedUser;

    catch (Exception ex)

        throw ex;

    finally

        if (pExistingTokenHandle != IntPtr.Zero)

            CloseHandle(pExistingTokenHandle);

        if (pDuplicateTokenHandle != IntPtr.Zero)

            CloseHandle(pDuplicateTokenHandle);

Vaya, esto es Impersionante...

Cabe destacar que en la llamada a LogonUser, se pasa un puntero al token de usuario 'pExistingTokenHandle' que posteriormente se usa en la llamada a DuplicateToken. Ésta devuelve el duplicado mediante 'pDuplicateTokenHandle', que posteriormente es usado para crear una nueva identidad y llamar a su método Impersonate, que es realmente la que se encarga de realizar la suplantación con el nuevo token.

(*) El siguiente código no funcionará en plataformas Windows 98 o Windows Me, ya que no poseen la posibilidad de trabajar con tokens de usuarios.

Una vez realizado el trabajo que requería de la suplantación de identidad, para volver al contexto predeterminado basta con invocar al método Undo del objeto WindowsImpersonationContext del siguiente modo:

Security.SecurityContext sec = new Security.SecurityContext();

if (Properties.Settings.Default.SaveResultsUsingImpersonation)

    sec.ImpersonateUser(

        Properties.Settings.Default.ImpersonateUser,

        Properties.Settings.Default.ImpersonateDomain,

        Properties.Settings.Default.ImpersonatePwd);

    appEventLog.WriteEntry(

        string.Format("Begin Impersonation, Current user as {0}",

        WindowsIdentity.GetCurrent().Name));

//

//Realizar acciones que requieren suplantación..

//

if (Properties.Settings.Default.SaveResultsUsingImpersonation)

    sec.ImpersonationContext.Undo();

    appEventLog.WriteEntry(

        string.Format("End Impersonation, Current user as {0}",

        WindowsIdentity.GetCurrent().Name));

Conclusión

Espero que este post haya clarificado cómo realizar este proceso. En el siguiente veremos cómo encapsular toda la aplicación para ejecutarse en forma de servicio. Ah! y antes que me lo diga alguno, ya se que no sería el mejor ejemplo para mostrar un servicio de Windows (porque corriendo con permisos de LOCALSYSTEM no se tiene permiso a la caché del usuario), pero tenía un post al respecto pendiente desde hace tiempo. Así que lo juntaremos todo en un mix o refrito o como queráis llamarlo, para que sirva de ejemplo.

También al final de la serie, postearé un recopilatorio de los pasos que hemos seguido y el código completo del ejemplo, por si alguien está tan loco como para querer probarlo :-P

Ahora, a impersonar todos. Pero si lo hacéis, por favor hacerlo bien... no de este modo:

Saludos desde Andorra

** crossposting desde el blog de Lluís Franco en geeks.ms **

Acceder a la caché de Internet Explorer (II)

lfranco — Tue, 20 May 2008 17:07:25 GMT

:-/
Hola de nuevo,

Siento haber tardado más de lo previsto en publicar este post, pero hemos tenido un fallecimiento en la familia este fin de semana y todavía andamos un poco descolocados. De todos modos, siguiendo con el hilo del primer post de esta serie, vamos a ver como leer los valores de los archivos temporales de Internet (imágenes que son almacenadas en caché, cookies, sitios visitados, etc.). Para acceder al contenido de esta caché vamos a usar un par de llamadas al API de windows y vamos a guardar el contenido de estas consultas en un medio persistente para su posterior análisis.

El objetivo de todo esto:

Nuestro objetivo va a consistir en recoger información de la caché cada X tiempo (supongamos cada hora), y mediante serialización persistirla en ficheros XML en una ubicación remota. Además, para complicarlo un poquito más vamos a hacer que esta ubicación no sea accesible desde el usuario actual, de modo que debamos impersonar otro inicio de sesión que si tenga permisos sobre esta ubicación. Todo esto, lo encapsularemos como un servicio de Windows y crearemos un proyecto de instalación que podremos distribuir en los clientes que deseamos inspeccionar.

Una vez terminado este ejercicio habremos mostrado varias cosas como:

Acceder a la caché de Internet Explorer
Serializar objetos a ficheros XML
Impersonar la ejecución de nuestra aplicación con otro usuario
Crear un servicio de Windows que ejecute un proceso cada X tiempo

De todos modos me gustaría dejar clara una cosa, para que nadie me malinterprete:

** El objetivo de todo esto no es ni mucho menos crear una herramienta para espiar a nadie, si no que lo he considerado más bien como un projecto que reune varias cosillas interesantes a explicar, un modo de reunirlas bajo un mismo ejercicio **

Preparando el terreno:

El primer paso va a ser declarar una clase que almacene la información de las entradas devueltas por las funciones FindFirstUrlCacheEntry y FindNextUrlCacheEntry.

[Serializable]

public class IECacheEntry

    public string url;

    public string size;

    public string lastAccessTime;

    public string lastModifiedTime;

    public string expireTime;

    public string filename;

    public IECacheEntry()

    public IECacheEntry(

        string _url,

        string _size,

        string _lastAccessTime,

        string _lastModifiedTime,

        string _expireTime,

        string _filename)

        url = _url;

        size = _size;

        lastAccessTime = _lastAccessTime;

        lastModifiedTime = _lastModifiedTime;

        expireTime = _expireTime;

        filename = _filename;

Esta clase la vamos a usar conjuntamente con esta clase, que identifica la consulta y recoge los datos que se guardarán cada vez que se ejecute la consulta a la caché. Esta clase también la decoraremos con el atributo serializable para posteriormante poder persistirla a un fichero XML:

[Serializable]

public class IECacheQuery

    public IECacheQuery() { }

    public string hostname = string.Empty;

    public string username = string.Empty;

    public DateTime date = DateTime.Now;

    public List<IECacheEntry> results;

Empezando a ensamblar las piezas:

EL corazón de este ejercicio consiste en esta pequeña función "getResults", que a partir de una cadena que contiene el patrón de búsqueda devuelve todas las instancias de la caché que coinciden con ésta. Este patrón de búsqueda puede contener el valor "cookies", "visited", una URL en concreto o bien NULL (que devuelve todos los valores de la caché). A continuación estos resultados se almacenan en una lista genérica que se devuelve como valor de retorno de la función.

Nota 1: Este código se ha realizado con compatibilidad con estaciones Windows 2000 que admiten versiones del Framework hasta la 2.0, de modo lamentablemente que no se han podido utilizar las bondades del Framework 3.5 (en particular he echado mucho de menos a LINQ to objects).

Nota 2 : En el código pueden observarse llamadas a funciones que no han sido descritas en el artículo (como el método ToStringFromFileTime en el código siguiente). Sin embargo estas funciones si pueden encontrarse en el código completo del ejemplo que se podrá descargar al final de la serie.

private List<IECacheEntry> getResults(string patternText)

    List<IECacheEntry> listresults = new List<IECacheEntry>();

    List<IECacheAPI.INTERNET_CACHE_ENTRY_INFO> results =

        IECacheAPI.FindUrlCacheEntries(patternText);

    foreach (IECacheAPI.INTERNET_CACHE_ENTRY_INFO result in results)

        IECacheEntry entry = new IECacheEntry();

        listresults.Add(

            new IECacheEntry

                    result.lpszSourceUrlName,

                    ((((Int64)result.dwSizeHigh) << 32) + result.dwSizeLow).ToString(),

                    Win32API.ToStringFromFileTime(result.LastAccessTime),

                    Win32API.ToStringFromFileTime(result.LastModifiedTime),

                    Win32API.ToStringFromFileTime(result.ExpireTime),

                    result.lpszLocalFileName

);

    return listresults;

Bien, de momento ya tenemos la función encargada de devolver los resultados de la caché, ahora ¿que hacemos con ellos?

Persistir objetos, que facil es con .NET!

Serializar objetos a XML es muy pero que muy sencillo. De hecho en nuestro caso ni siquiera vamos a aplicar un formateador SOAP ni binario, y tampoco vamos a aplicar atributos para serializar miembros de clases como nodos o atributos. En este caso vamos a usar la serialización del siguiente modo:

public sealed class Manager

        public static void Save(IECacheQuery query, string pfilename)

try

                XmlSerializer xmlDoc = new XmlSerializer(typeof(IECacheQuery));

                StreamWriter sw = new StreamWriter(pfilename);

                xmlDoc.Serialize(sw, query);

                sw.Close();

            catch (Exception ex)

                throw ex;

A esta función se le pasan dos argumentos, el objeto que deseamos persistir i el nombre del archivo XML en el que se quiere persistir. En ella se crea un objeto XmlSerializer preparado para el tipo de objeto IECacheQuery, a continuación se crea un Stream al fichero XML para serializar el objeto. A continuación se cierra el Stream y se acabó lo que se daba.

Qué? Facil verdad? Esta es una de las maravillas que me cautivaron cuando empecé con .NET (y es que con anterioridad había que hacer maravillas para poder realizar este tipo de cosas).

Próximos pasos:

De momento ya tenemos la función que devuelve resultados de la caché y tenemos un modo de persistir un objeto en un fichero XML. A continuación, después de la publicidad (o más bien en el próximo post), mostraremos como Impersonar nuestra aplicación para que se ejecute como otro usuario, a fin de tener acceso a una supuesta ubicación de red en la que gusrdar los ficheros de resultados.

Hasta el próximo post.

** crossposting desde el blog de Lluís Franco en geeks.ms **

Acceder a la caché de Internet Explorer (I)

lfranco — Thu, 15 May 2008 16:59:45 GMT

En algunos casos puede ser interesante acceder a la caché de navegación de Internet Explorer. Por ejemplo, para poder guardar un registro de los sitios que visitan los usuarios de nuestra organización sin tener que montar un ISA server o similar.

Para ello, y como todavía no he encontrado nada implementado en el propio Framework, vamos a hacer uso de algunos elementos del API de Windows. Ese gran amigo que todavía nos sigue sacando las castañas del fuego algunas veces... :-D

El punto de partida:

Cuando accedemos a la carpeta de archivos temporales de Internet, podemos eliminar el contenido o cambiar la ubicación de la carpeta que utilizamos para almacenar este información:

Incluso si pulsamos la opción de ver archivos, el explorador nos muestra una vista similar a esto:

Sin embargo, esta vista se genera automáticamente a partir del contenido de un fichero llamado Index.dat, que se encuentra en la carpeta "Archivos temporales de Internet\Content.IEX", siendo X la versión de IE del sistema. De modo que, para poder acceder a la información contenida en este fichero no nos queda más remedio que utilizar algunas funciones del API de Windows.

Presentando a los protagonistas:

Como os decía anteriormente, a falta de poder usar código manejado vamos a utilizar los ladrillos del propio S.O.

Esta estructura representa un elemento dentro de la caché de Internet.

[StructLayout(LayoutKind.Sequential)]

public struct INTERNET_CACHE_ENTRY_INFO

    public UInt32 dwStructSize;

    public string lpszSourceUrlName;

    public string lpszLocalFileName;

    public UInt32 CacheEntryType;

    public UInt32 dwUseCount;

    public UInt32 dwHitRate;

    public UInt32 dwSizeLow;

    public UInt32 dwSizeHigh;

    public Win32API.FILETIME LastModifiedTime;

    public Win32API.FILETIME ExpireTime;

    public Win32API.FILETIME LastAccessTime;

    public Win32API.FILETIME LastSyncTime;

    public IntPtr lpHeaderInfo;

    public UInt32 dwHeaderInfoSize;

    public string lpszFileExtension;

    public UInt32 dwExemptDelta;

};

Más información acerca de esta estructura en:

INTERNET_CACHE_ENTRY_INFO Structure

http://msdn.microsoft.com/en-us/library/aa385134(VS.85).aspx

También nos basaremos en estas dos funciones, encargadas de devolver un puntero a un elemento del tipo INTERNET_CACHE_ENTRY_INFO dentro de la caché. La primera de ellas devuelve el primer valor encontrado en la caché, a partir de un puntero a una cadena que representa el patrón a buscar. Mientras que la segunda recibe el manejador devuelto por la primera llamada a FindFirstUrlCacheEntry.

[DllImport("wininet.dll", SetLastError=true)]

private static extern IntPtr FindFirstUrlCacheEntry(

  string lpszUrlSearchPattern, IntPtr lpFirstCacheEntryInfo,

  out UInt32 lpdwFirstCacheEntryInfoBufferSize );

[DllImport("wininet.dll", SetLastError=true)]

private static extern long FindNextUrlCacheEntry(

  IntPtr hEnumHandle, IntPtr lpNextCacheEntryInfo,

  out UInt32 lpdwNextCacheEntryInfoBufferSize );

Podéis encontrar más información acerca de ellas en:

FindNextUrlCacheEntry Function
http://msdn.microsoft.com/en-us/library/aa384049(VS.85).aspx

FindFirstUrlCacheEntry Function
http://msdn.microsoft.com/en-us/library/aa384026(VS.85).aspx

Y ahora que?

Pues ahora nada, que me he quedado sin tiempo... hasta aquí este primer post. Mañana continuaremos con la construcción de un pequeño proyecto de ejemplo que utiliza estas funciones para acceder a la caché de Internet y muestre el contenido en pantalla. Y si da tiempo, sería interesante crear una aplicación o servicio que vaya monitorizando y guardando este contenido en algún medio persistente (tal vez XML o una base de datos).

Hasta mañana!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Los viejos rockeros nunca muere, o soporte a VB6 en Windows 2008

lfranco — Mon, 17 Mar 2008 10:36:17 GMT

Está claro que todavía existe un gran parque de aplicaciones realizadas en VB6, muchas de las cuales todavía no han podido ser migradas, o mejor dicho rediseñadas para la plataforma .NET, ya sea por falta de tiempo, recursos, etc.

Para todos aquellos que (como yo) estaban sufriendo con la llegadas de los nuevos sistemas operativos Vista y Windows 2008, el equipo de VB nos informa de algunas de las mejoras del soporte del runtime en estos sistemas:

http://blogs.msdn.com/vbteam/archive/2008/03/15/improvements-to-visual-basic-6-runtime-support-on-vista-windows-server-2008-by-paul-yuknewicz.aspx

Y en el siguiente artículo todavía se detalla más:

http://msdn2.microsoft.com/en-us/vbrun/ms788708.aspx

No deja de ser una noticia curiosa en estos tiempos, pero hay que pensar que no todos tenemos la suerte de trabajar con las nuevas tecnologías, y que en ocasiones todavía tenemos que ponernos el antiguo mono de trabajo para mantener algunas viejas (y buenas) aplicaciones.

Nos leemos,

** crossposting desde el blog de Lluís Franco en geeks.ms **