Momenteel gebruiken we op mijn werk Domino 5.0.11. Domino 5 wordt sinds april 2004 echter niet meer uitgeleverd door Lotus en de support zal aflopen op april 2005. Dit valt te lezen in technote #1117092 (End of Service (EOS) of Lotus Notes and Domino 5.x) op de Lotus support website. Daarnaast wordt Domino 5.0.11, wel 5.0.12, 5.0.13 en 6.0.1 en hoger, niet ondersteund op AIX 5.2. Twee goede redenen voor mijn werkgever om te gaan upgraden naar Domino 6.5.1.
Voordat je kan gaan upgraden dien je eerst een risico analyse te maken voor je bestaande Domino applicaties. Hiermee ben ik momenteel belast. Een van de bevindingen is dat als we naar een LEI 6.x versie gaan de gebruikte LEI LSX aanroep in onze LEI scripted agents dienen te vervangen. De huidige aanroep Uselsx "*lsxlei"
dient vervangen te worden door Uselsx "*lsxlc"
.
Een ander belangrijk punt betreft voor ons LDAP en de samenhang daarvan met secundaire Domino adresboeken. Dit in verband met de samenwerking met onze WebSphere Application Server. In het secundaire adresboek registreren we de accounts voor ons extranet. Het domein van deze account is geen officiƫle Notes certifier. Bij testen op een ND6.5.1 server kon ik met de Softerra LDAP browser tool geen entries zien uit het secundaire adresboek. Een stukje Java code dat een LDAP uitvraag deed kreeg daarentegen wel resultaten terug. Naar enig uitzoekwerk bleek dit probleem veroorzaakt te worden door het ontbreken van LDAP 'organizationalUnit' documenten in het secundaire adresboek voor onze fictieve Notes domein. De LDAP server genereerd deze alsnog door het volgende server commando op de server console in te voeren: 'tell LDAP VerifyDIT
'. Na dit gedaan te hebben kreeg ik alsnog de documenten uit de secundaire adresboek te zien. De noodzaak van de aanwezigheid van deze 'organizationalUnit' documenten is blijkbaar een belangrijke wijziging van de werking van LDAP in Domino 6.x.
Zoals ieder systeem heeft Active Directory ook zijn limieten. Tijdens wat Active Directory research kwam ik het volgende Technet artikel tegen waarin deze worden benoemd: Active Directory Maximum Limits . Kort samengevat zijn de limieten: Maximum aantal objecten per domain controller in een forest : ongeveer 2,5 biljoen (gedurende de volledige levensduur). Maximum aantal security identifiers (SID's) per domein : ongeveer 1 biljoen (gedurende de volledige levensduur). Aantal groepen waarvan een security indentifier (persoon, groep, computer account) lid kan zijn : ongeveer 1.015 groepen. FQDN lengte limiet : maximum lengte is 64 tekens (dit is inclusief punten en mintekens) voor de fully qualified domain name (FQDN). Bestandsnaam limiet : Windows kent een pad lengte limiet van 260 tekens. Deze is ook van toepassing op de fysieke bestanden van AD zoals SYSVOL. Organisational unit limiet : maximum lengte is 64 tekens. Heeft te maken met de Windows limiet van 260 tekens die in de gaten
Reacties