10 Years Later: The Hell and Glory of Installing FileNet Daeja Viewer

10 Years Later: The Hell and Glory of Installing FileNet Daeja Viewer

Back in 2015 I had to pull off one of those invisible masterpieces that leave a mark in your career: building IBM FileNet P8 + Content Navigator + Daeja Viewer from scratch, on top of Windows Server, WebSphere, DB2, and Active Directory.

It wasn’t plug-and-play. I went through 100+ virtual machines, breaking and rebuilding, until LDAP, JAAS, CE, ICN, and DB2 finally came together. While some colleagues said “this is too difficult,” I was neck deep in LDAPS, certificates, Kerberos SPNs, WebSphere JVM tuning, and those endless logs that only make sense at 3 a.m. After many sleepless nights, the system finally went live in Sydney, Darling Harbour.

---

The Number One Enemy: Daeja ViewOne

This viewer was both hated and necessary. Without it, PDFs and TIFFs would not render at all. Typical WebSphere log error looked like this:

[5/18/15 11:01:32:341 BDT] 000000cd LocalTranCoor E   
WLTC0017E: Resources rolled back due to setRollbackOnly()

FNRAC1008E: Unable to get data from server

[FNRPE0911843060E] Error executing the CA RPC call configEventExportStoreProperties
Root cause: java.lang.NullPointerException

Translation: the viewer was trying to fetch Content Engine configuration and died with a NullPointerException. If you didn’t know how to read between the lines, you could be stuck for days.

---

The Classic jiServerException Bug

Sometimes, when opening a TIFF in ICN, you’d hit this random error:

ji.net.jiServerException: Server did not respond with OK
Error: IO error: null

Open the same document a second time — and suddenly it worked. Root cause? HttpOnly cookies in WebSphere. IBM documented this years later, but back then it was all about trial and error.

Fix (WebSphere 8+):

1. Go to Servers > Server Types > WebSphere Application Servers > Session Management.
2. Uncheck Set session cookies to HTTPOnly.
3. Go to Global Security > Web and SIP Security > Single Sign-On (SSO).
4. Uncheck Set security cookies to HTTPOnly.
5. Restart the node.
   

And finally, Daeja would behave.

---

LDAP / Active Directory: The Real Challenge

Authentication was a nightmare if you didn’t master LDAP + Kerberos. These snippets saved my life back then:

SPN for the service account:

setspn -S HTTP/filenet-appsrv DOMAIN\svc-fn-was
setspn -S HTTP/filenet-appsrv.domain.local DOMAIN\svc-fn-was

Optimized LDAP filters:

(&(objectClass=user)
  (!(userAccountControl:1.2.840.113556.1.4.803:=2))
  (|(memberOf=CN=FN_Users,OU=Groups,DC=domain,DC=local)
    (memberOf=CN=ICN_Users,OU=Groups,DC=domain,DC=local)))

Testing LDAPS from PowerShell:

Test-NetConnection -ComputerName dc01.domain.local -Port 636

---

Lessons of a Mexican Engineer in Sydney 🇲🇽🌏

Looking back, I see that work as an invisible masterpiece. Nobody documented the fine-tuned configs I made, but that environment likely kept running 10 years later.

What I learned:

• FileNet was never for “manual installers” — it was for engineers who understood the guts of the system.
• Many of the fixes we discover at 3 a.m. never make it into IBM’s official manuals, yet they keep mission-critical systems alive.
• And yes: Mexicans can leave a mark anywhere — even in Darling Harbour.

---

#FileNet #IBMFileNet #ContentNavigator #DaejaViewer #WebSphere #DB2 #ECM #EnterpriseContentManagement #LDAP #ActiveDirectory #Kerberos #JavaEE #WAS #IBMCloudPak #SystemIntegration

Sydney will always remain more than just a project site for me. While others enjoyed Darling Harbour’s sunsets and the lights of the Opera House, I was deep in WebSphere logs, LDAP filters, and NullPointerExceptions. Yet, in between sleepless nights and 100+ virtual machines rebuilt from scratch, I felt the same energy of the city itself — resilient, alive, and relentless.

Ten years later, I look back and realize that my work was not only lines of code or system configs, but a piece of me left in that harbor, quietly running inside servers that still power critical processes. Sydney gave me sleepless nights, but also the memory that Mexican engineers can leave a mark anywhere in the world.

---

Español
Sídney siempre será mucho más que un simple lugar de proyecto para mí. Mientras otros disfrutaban de los atardeceres en Darling Harbour y las luces de la Ópera, yo estaba sumergido en logs de WebSphere, filtros LDAP y NullPointerExceptions. Sin embargo, entre desveladas y más de 100 máquinas virtuales reconstruidas desde cero, sentí la misma energía de la ciudad: resiliente, viva y persistente.

Diez años después, miro hacia atrás y me doy cuenta de que mi trabajo no fueron solo líneas de código o configuraciones de sistema, sino una parte de mí que quedó en ese puerto, corriendo en silencio dentro de servidores que aún sostienen procesos críticos. Sídney me dio noches sin dormir, pero también el recuerdo de que los ingenieros mexicanos podemos dejar huella en cualquier lugar del mundo.

ACTIVE DIRECTORY WINDOWS SERER 2008 R2 ENTERPRISE EDITION

AD0001 - Creando nuestro primer Active Directory en Windows Server 2008 R2

Como no podía ser de otra manera, en éste primer post de mi nuevo blog veremos como crear nuestro primer Active Directory utilizando Windows Server 2008 R2.
Para quienes no lo sepan, Active Directory es uno de los tantos componentes que vienen dentro de Windows Server 2008 R2 y que nos hará de base para armar nuestra red lógica empresarial. Desde el AD (Active Directory) podremos centralizar todos los recursos tales como usuarios, computadoras, impresoras, grupos de distribución, grupos de seguridad entre otros pero principalmente tendremos Identidad y Acceso a nuestra red.
Para poder poner en marcha nuestro primer AD, precisamos contar con al menos un servidor con Windows Server 2008 R2 instalado, en nuestro caso con Service Pack 1 ya instalado como también todos sus updates.
Antes de empezar con la instalación y configuración de nuestro AD, debemos cumplir con un check list esencial:

• Nombre del host: nuestro servidor debe tener el nombre adecuado que queramos, ya que lo recomendado es que una vez configurado nuestro AD, el nombre de host no se cambie.
• IP: adicionalmente al nombre de host, el servidor debe contar con una IP fija, la cual debemos establecerla según la red que estemos armando.
• Nombre de dominio: este punto es muy importante dado que representa en la mayoría de los casos a la organización o compañía. Si bien podemos elegir como dominio, uno propio que ya dispongamos en Internet, se recomienda que éste sea de uso exclusivo de uso interno de nuestra red. Si nuestro dominio en Internet es mswin.org, lo ideal para nuestro AD sería mswin.local o mswin.corp o similares.

1) Cambiando el nombre de host a nuestro servidor:
1.1) Vamos a Start y hacemos clic con el botón derecho del mouse sobre Computer y elegimos Properties

1.2) Luego en la ventana de System, veremos el actual nombre de nuestro servidor y para cambiarlo debemos hacer un clic sobre Change settings.

1.3) Ahora hacemos un clic en Change

1.4) En este paso debemos darle el nombre que queramos y luego hacer un clic en Ok.

1.5) Debido a que cambiamos el nombre de nuestro servidor, el sistema nos pedirá un reinicio para que aplique los cambios, lo cual aceptamos y luego lo reiniciamos.


2) Cambiando la IP de nuestro servidor
2.1) Para cambiar la IP de nuestro servidor, debemos acceder a las propiedades del adaptador de red. Para ello, hacemos un clic en el icono de red tal como se muestra en la siguiente imagen, y seleccionamos “Open Network and Sharing Center”

2.2) Luego en la ventana de Network and Sharing Center, seleccionamos “Change adapter settings”

2.3) En este paso, debemos seleccionar el protocolo “Internet Protocol Version 4 (TCP/IPv4)” y apretar en el boton deProperties.

2.4) Ahora debemos ingresar la IP correspondiente para nuestro servidor como así también la Subnet Mask, el Default Gateway y el DNS Primario. Estos últimos dos ítems, llevan la misma IP que nuestro servidor. En el caso del DNS es debido a que nuestro primer servidor de AD también será nuestro primer DNS, servicio básico para que Active Directory funcione.

3) Instalando y Configurando Active Directory Domain Services (AD DS) Role
3.1) Una vez que tenemos listo los pasos anteriores, estaremos preparados para iniciar la instalación de nuestro primer Domain Controller. Existen varias formas para poder instalar el rol de AD DS, pero en este caso utilizaremos el comandodcpromo.exe para iniciar el proceso.
Vamos a Start – Run y en Open escribimos dcpromo y luego hacemos un clic en Ok.
Luego debemos esperar a que se instalen los archivos necesarios para poder comenzar con el proceso.

3.2) Ahora veremos que se abre el “Active Directory Domain Services Installation Wizard”, donde nos dará la opción de usar el modo avanzado de instalación el cual no utilizaremos en este caso. Para avanzar tan solo apretamos en Next.

3.3) En la pagina de “Operating System Compatibility” podemos revisar cuales son las opciones de seguridad por defecto en los controladores de dominio de Windows Server 2008 y Windows Server 2008 R2. Aquí tan solo lo leemos y avanzamos con Next.

3.4) En este punto, dado que no tenemos ningún Forest creado, crearemos uno nuevo seleccionando “Create a new domain in a new forest” y luego hacemos un clic en Next.

3.5) Ahora debemos ingresar el nombre que le daremos a nuestro dominio, en nuestro caso será mswin.corp y luego seleccionamos Next, donde el sistema chequeará que los nombre del DNS y NetBIOS no estén en uso ya en nuestra red.

3.6) En la pagina de “Set Forest Functional Level” debemos seleccionar el nivel de funcionamiento que queramos que tenga nuestro dominio y dependiendo de esto, tendremos mas o menos características habilitadas, como así también mayor o menor seguridad en nuestro dominio. En nuestro caso seleccionamos Windows Server 2008 R2. Luego seleccionamos Next.

3.7) En la pagina de “Additional Domain Controller Options”, la opción de DNS server ya está marcada por defecto, dado que el proceso de instalación creará la zona necesaria. Las opciones sin posibilidad de cambio son debido a que el Global Catalog es necesario para nuestro primer DC y adicionalmente éste no puede ser un Read-Only. Seleccionamos Next para avanzar.

3.8) Recibiremos una advertencia que la delegación para el DNS Server no podrá ser creada. Podemos ignorar este mensaje y avanzar seleccionando en Yes.

3.9) Ahora debemos seleccionar el path donde alojar la Base de Datos, los Log Files y la SYSVOL folder. Si bien podemos dejar estas opciones de forma predeterminada, en ambientes productivos se recomiendan separar en tres volúmenes de discos diferentes, que no tengan aplicaciones o archivos que no estén relacionadas con el rol de AD DS. Este ayuda a tener mejor performance e incrementa la eficiencia de backup y restore. Dado que en nuestro caso es una demo, dejamos las opciones por defecto y hacemos un clic en Next.

3.10) Ahora ingresaremos una clave compleja que se utilizará para el Directory Services Restore Mode Administrator. Luego seleccionamos en Next.

3.11) En la pagina de Summary, podremos revisar todas las opciones que seleccionamos anteriormente. También podremos exportar la configuración para utilizarla en otro momento. Para iniciar la instalación y configuración seleccionamos en Next. Luego el sistema pedirá reiniciar al seleccionar en Finish.


4) Tareas posteriores a la instalación del rol AD DS
4.1) Lo primero que debemos hacer luego del reinicio es iniciar sesión en el dominio y revisar en el Event Viewer los eventos y chequear que éstos no tengan relevancia alguna. En caso de tener eventos importantes debemos proceder con la solución de los mismos.
4.2) Otra de las cosas que podemos hacer es iniciar la consola de Active Directory Users and Computers desde donde administraremos los objetos tales como Usuarios, Grupos y equipos entre otros. Para iniciar dicha consola podremos hacerlo desde Start – Administrative Tools y allí seleccionamos Active Directory Users and Computers. Otra forma de hacerlo mas rápidamente es desde Start – Run y allí escribimos dsa.msc y le damos Enter.



Conclusión:
En este primer articulo hemos visto como preparar nuestro primer Domain Controller en Windows Server 2008 R2. En próximos artículos veremos otras funcionalidades de Active Directory.
Espero que les sea de utilidad.
Saludos,