~ Just do I(nformation)T(echnology) ~

Oktober rollup is vrijgegeven

Eergisteren is de oktober rollup vrijgegeven. Daarnaast is er een losse fix voor problemen met workflow vrijgegeven.
Je kunt de fixes vinden op: 

WSS 3.0 Global
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957691&kbln=en-us

MOSS 2007 Global
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957693&kbln=en-us

MOSS 2007 Taal specifiek
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=958567&kbln=en-us

MOSS 2007 Workflow Hotfix
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=958569&kbln=en-us

 ....

Timer Job Cache

Als je problemen ondervindt met timer jobs die niet willen draaien of vastlopen, of rare errors krijgt tijdens het draaien van PSCONFIG, kan het verstandig zijn de configuratie cache van de timer service eens te flushen. Soms is deze data corrupt en kan een rebuild de oplossing zijn van de rare problemen. Om dit te doen doe je het volgende:

1. Stop de Windows SharePoint Services Timer service op alle sharepoint servers in de farm (NET STOP SPTimerV3).
   
   Vervolgens voor je op de volgende servers in exact deze volgorde de onderstaande stappen uit: 1. Index server, 2.Query server, 3. Web front end server, 4. Applicatie server
   
   
2. Browse naar <n>:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<GUID>
3. Verwijder alle XML bestanden in deze directory
4. Edit de cache.ini en verander het nummer naar 1.
5. Start de Windows SharePoint Services Timer service op de server (NET START SPTimerV3)
6. Wacht tot je weer XML bestanden ziet verschijnen voordat je naar de volgende server gaat

Maak je geen zorgen, je maakt niets stuk J

Search results worden niet juist weergegeven door limiet op ACL grootte

Onlangs ben ik voor de tweede keer een probleem tegen gekomen bij een klant waar de resultaten van Sharepoint Enterprise Search niet juist worden weergegeven door een limitatie van de buffer van de WIN32 API InitializeAcl functie, welke gebruikt wordt door de indexer wanneer deze de wijzingen bepaald voor de index.
Deze buffer is 64KB groot, wat inhoudt dat de ACL's op objecten in sharepoint niet meer entries mogen bevatten dan in de buffer opgeslagen kan worden.

Hoeveel entries zijn dat dan??? … Nou dat hangt er bijvoorbeeld vanaf hoeveel groepen een userobject lid van is, en wat het SIDhistory property op zijn/haar AD object voor waardes bevat. Daarnaast zijn er nog enkele andere eigenschappen van een security object wat de grootte van een enkele ACE bepaald.
Om het makkelijk te maken zou ik zeggen dat +-1000 entries teveel is.

Het maakt hier niets uit of je de gebruikers los hebt toegekent of eerst lid hebt gemaakt van een Sharepoint Group. De enige manier om te zorgen dat de indexer niet tegen het limiet aanloopt, is de gebruikers te organiseren in AD Groups en deze in de ACLs op te nemen.

Dit probleem geldt voor zowel Office Sharepoint Server 2007 als Sharepoint Portal Server 2003

De foutcode die de indexer geeft bij het crawlen van een item is PRTH_E_ACL_TOO_BIG (0x80041211L) 

....

Werken met Sharepoint ULS logs

Iedereen die met Sharepoint gewerkt heeft vanuit een infrastructuur oogpunt, weet dat de ULS logs van Sharepoint erg omvangrijk kunnen zijn. Vooral als bepaalde categorien op verbose gezet zijn. Deze post gaat over hoe je het voor jezelf makkelijker kan maken om met de logs te werken.

Om gemakkelijker verbose logs te verzamelen doe je het volgende:

·         Draai het volgende commando:
stsadm –o setlogginglevel –default

Op dit moment heb je een enkele (hopelijk kleinere) logfile in de logging directory in 12 hive.

Er zijn op dit moment geen makkelijke tools van Microsoft om sharepoint logs te analyseren, maar verschillende klanten gebruiken tools als:

Log Parser 2.2: http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

Sharepoint Logging spy vind ik persoonlijk een erg complete tool, welke je ook in staat stelt logs van meerdere servers te consolideren en te doorzoeken.

Process Monitor is the Bomb!!

Zojuist was ik bezig met het schrijven van een blogpost om de Microsoft Loopback Adapter te gebruiken in combinatie met Internet Connection Sharing om zo een 'NAT-achtige' structuur te maken voor mijn Virtual PC 2007 VM's. Dit omdat de NAT functionaliteit van VPC, de VM's niet toestaat onderling te communiceren.

Ik had dit al eerder gedaan op XP machines, maar er zit een valkuil in de procedure voor Vista, welke ik documenteren op mijn blog. Echter...toen ik eenmaal zover was om ICS te gaan gebruiken kwam ik het volgende venster tegen:

 ...CRAP...$%#%$ 

 duidelijk gevalletje Microsoft IT GPO... :)

Nu ben ik administrator op mijn laptop, dus ging dit policietje mij natuurlijk niet tegenhouden. Maar... Wat is precies de locatie van deze policy?? Er zijn honderden policysettings. Waar te beginnen??
Policysettings worden weggeschreven in het register. Voor user settings zijn ze te vinden in HiveKey Current User (HKCU) en voor computer settings in HiveKey Local Machine (HKLM). Bij het opstarten en periodiek worden de policy settings opgehaald vanaf het domain en weggeschreven in het register. Vervolgens worden ze uitgelezen door de applicaties waarvoor ze bedoeld zijn. Dit kan tijdens het opstarten zijn (een groot deel van de policies worden uitgelezen door EXPLORER.EXE (window manager) tijdens het opstarten), maar ook wanneer de functionaliteit die het betreft, gebruikt wordt.

Ik zou domweg door het register kunnen gaan spitten, maar zoals ik al aangaf, zijn er teveel plekken waar de setting zou kunnen staan. Ook zou ik de GPO settings lijst van Vista kunnen downloaden van http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b-3328-4350-ade1-c0d9289f09ef&DisplayLang=en en de desbetreffende policy kunnen zoeken tussen de 2495 settings, maar dat is ten eerste niet leuk en ten tweede dacht ik sneller te werken op mijn eigen manier. En die manier is via Process Monitor van SysInternals.

Ik gokte dat de policy setting uitgelezen werd op het moment dat ik het property window opende van mijn netwerk connectie die ik wilde sharen.
Wat ik dus deed was Process Monitor starten in registry mode en het probleem reproduceren.
Vervolgens stopte ik de trace en gebruikte ik de 'Include Process from Window' optie om een filter te zetten op mijn trace.
Met het vizier kan je een window aanklikken, waarop Process Monitor bepaald welk process er bijhoort en het filter op de trace aanpast. Het venster behoorde tot een DDLHOST.EXE process wat het OS gebruikt om out-of-process applicaties zoals COM servers te hosten.
In dit geval was de command line syntax: C:\Windows\system32\DllHost.exe /Processid:{7007ACD1-3202-11D1-AAD2-00805FC1270E}.

Een snelle query in Component Services en het register laat weten dat het om de Network Common Connections Ui DCOM applicatie gaat, welke voornamelijk functies uit de NETSHELL.DLL gebruikt. Gezien de naam zou ik nu al zeggen dat we in de buurt zitten.

De volgende stap was om wat extra filters te zetten op de trace. Policies staan in het register altijd in een path wat de naam policies bevat. Ook moeten de read actie op het register de status SUCCESS hebben gehad om het mogelijk gemaakt te hebben de key uit te lezen. Zoals je in het venster rechts kan zien zijn er nu dus een aantal filters van toepassing.
De PID 5844 filter is gezet door de 'Include Process from Windows' functionaliteit en de Result is SUCCESS en Path contains Policies heb ik zelf gezet, wat mij de volgende resultaten geeft:

Zoals je ziet zijn er een aantal policies die uitgelezen worden. De 3 onderaan de trace hebben mijn aandacht. De NC_ShowSharedAccessUI en NC_AllowNetBridge_NLA zijn na onderzoek degene die ik moet hebben. De volgende stap is om in het register de permissies van de key die de settings bevat af te halen. Ik geef EVERYONE deny READ. In sommige gevallen wordt het je wat lastig gemaakt, maar door de Take OwnerShip priviledges van de Administators Group kunnen we deze permissies eigenlijk altijd zetten. De Deny Read zorgt ervoor dat de policy gezien wordt als NOT CONFIGURED. Het resultaat is dat ik dus de Internet Connection Sharing gewoon aan kan zetten.

Easy does it...

 Zoals eerder gezegd kan het ook zijn dat de policies uitgelezen worden gedurende de boot. Gebruik dan de bootlogging optie van Process Monitor om erachter te komen om welke setting het gaat.

Natuurlijk is het niet de bedoeling GPO's te omzeilen, maar dit laat duidelijk zien dat GPO's geen enkele zin hebben als je toestaat dat je gebruikers LOCAL ADMIN zijn op hun laptops en werkstations.

Daarnaast is deze post voornamelijk bedoelt om te laten zien wat Process Monitor en ander tools van SysInternals voor geweldige hulpmiddelen zijn, die niet mogen ontbreken in de toolset van een SysAdmin...

:)