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...

:)

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

 ....

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

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  -tracelevel verbose

·         Restart de Windows SharePoint Services Tracing service (dit maakt een nieuwe logfile aan in de 12 hive).

·         Reproduceer het probleem.

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

·         Restart de Windows Sharepoint Services TRacing service.

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 Viewer at Codeplex: http://www.codeplex.com/features/Release/ProjectReleases.aspx?ReleaseId=2502

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

Sharepoint ULS Log Parser: http://www.codeplex.com/ShrptNinjaToolkit/Release/ProjectReleases.aspx?ReleaseId=15669

Sharepoint logging spy: http://www.codeplex.com/sharepointloggingspy

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.

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) 

....

Er bestaat regelmatig onduidelijkheid over welke patches nu geinstalleerd moeten worden om een farm naar het laatste patchlevel te brengen. Dit komt voornamelijk door onduidelijkheid over hoe nieuwe code released wordt binnen Microsoft. Wanneer je nu een farm opzet zou dit de laatste code set moeten zijn:

Release:

• Sharepoint Server 2007 RTM

Service Packs:

• WSS 3.0 Service Pack 1
• MOSS 2007 Service Pack 1

Feature Packs:

•  Infrastructure update WSS 3.0
•  Infrastructure update MOSS 2007

Update Rollups:

• WSS 3.0 August rollup taalspecifiek
•  WSS 3.0 August rollup global
•  MOSS 2007 August rollup global

Hotfix:

• Document LifeCycle hotfix

Security Update:

• Excel Services security bulletin

Dit brengt je farm naar patchlevel 6327.
Wanneer een update een global en taalspecifieke versie heeft, dien je eerst de global fix te installeren alvorens je voor elk languagepack (of SKU) een taalspecifieke fix installeert.

Ik druk jullie ook nogmaals op het hart.... Lees de update procedures!!!