Jan-v.nl weblog
Iedere keer wanneer we een Full-Text catalogus opnieuw moeten populaten is het weer een probleem. De optie Repopulate catalog is grijs en kun je dus niet starten via de interface. In SQL 2000 kon dit nog wel.

Inmiddels weten we dat dit niet kan en iedere keer lossen we het weer op door even 5 minuten te Googlen. Zelf vergeet ik namelijk altijd hoe dit gedaan moet worden, omdat je dit eigenlijk nooit doet.
Om daar nu van af te zijn post ik hier hoe je in MS SQL Server 2005 je full-text catalog opnieuw kunt populaten.
Het commando dat uitgevoerd dient te worden in SQL is het volgende:

EXEC sp_fulltext_catalog 'catalogname', 'start_full'

Logischerwijs is de catalogname uiteraard de naam van je full-text catalog. Dat behoeft volgens mij geen verdere uitleg.
Hopelijk was het vandaag de laatste keer dat ik dit op Google op moest zoeken.
De laatste tijd was ik bezig met het maken van een Sinterklaas website in Sharepoint (WSS 3.0 welteverstaan). Dit ging prima, totdat ik hem voor de buitenwereld beschikbaar wilde maken.
Via de AAM heb ik de website beschikbaar gemaakt voor de buitenwereld via een ander domein van mij. Dit werkte redelijk goed. Jammergenoeg kon ik de website niet onder poort 80 hosten, want het lijkt alsof Ziggo dat blokkeert. Nu heb ik dus maar een poort met een veel hoger nummer gebruikt.
Dit werkte ook goed en de hoofdpagina kon nu worden bekeken. Er was echter 1 groot probleem. Zodra iemand naar een andere pagina navigeerde kregen ze de melding 'Request Failed'. Het vervelende hieraan was, was dat er geen error informatie werd getoond in de logs of op het scherm. Ook kon ik hier geen logische verklaring voor geven.
Eerst dacht ik dat het misschien aan het poortnummer zou liggen, maar dat heb ik ook uitgesloten.
Uiteindelijk heb ik de web.config maar aangepast in de hoop dat ik meer informatie zou krijgen door de callstack="true" parameter aan te passen. Hier had ik geluk mee. Nu kreeg ik bij de 'Request Failed' melding een .Net foutmelding waar ik iets meer mee kon.
De exacte melding was iets als dit:


Request failed. at System.Reflection.Assembly._GetType(String name, Boolean throwOnError, Boolean ignoreCase)
at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError)
at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly)
at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData)

Niet echt veelzeggend, maar hier kon ik wel verder mee komen.
Via Google kwam ik op een weblog post van Corey Roth op de link http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/09/24/safe-mode-did-not-start-successfully-request-failed.aspx
Blijkbaar startte de safe-mode van Sharepoint niet op door een misconfiguratie in m'n web.config of systeem. Opeens had ik het. Onlangs had ik namelijk de CompleteSharepoint module zonder geinstalleerd ( http://www.completesharepoint.net/ ). Er waren echter wel allerlei regels in m'n web.config geplaatst en dll's in de bin-directory.
Deze regels heb ik uit de web.config verwijderd (van zowel de interne als externe url) en de bestanden uit de bin-directory van beide sites verwijderd.
Na het deinstalleren van de CompleteSharepoint module heb ik nog wel wat vervuiling op het systeem, maar voor nu kon ik in ieder geval verder.

Na het verwijderen heb ik wel weer een iisreset gedaan. Of dat nodig is weet ik niet, maar het kan natuurlijk nooit kwaad.

Ik had niet verwacht dat het probleem zo 'simpel' op te lossen zou zijn. In ieder geval kan m'n site nu worden gepubliceerd en kunnen we er voor het Sinterklaas feest gebruik van maken.
Zojuist wilde ik even veel foto's verkleinen van een dagje uit, zodat deze op Hyves geplaatst konden worden. Nu vind ik het niet zo enorm leuk om die tientallen foto's stuk voor stuk te openen in Paint of een ander foto bewerkingsprogramma.
Door even in Google een term in te vullen kwam ik bij de eerste hit al op een interessante pagina, namelijk deze: http://www.frontpagewebmaster.com/m-287285/tm.htm
Hier staat dat je met MS Office Picture Manager dit ook kunt doen, maar dan in bulk, precies wat ik zocht dus.

Het enige dat je hoeft te doen is de foto's in 1 map plaatsen, dan een van de foto's openen in Picture Manager.
Zorg dat je Thumbnail View hebt en daarna alle foto's selecteert met bijvoorbeeld [Ctrl]+[A]. Klik op de knop Edit Pictures en dan de optie Compress Pictures. Ik heb hier de optie Web pages gebruikt, maar iets anders kan natuurlijk ook. Onder File --> Save All kun je de wijzigingen dan opslaan voor alle plaatjes.

Best handig van het Office team om zoiets toe te voegen aan het pakket.
Aangezien ik de laatste tijd veel met Sharepoint bezig ben, moet ik ook wel geregeld lastige of (op het eerste gezicht) onmogelijke dingen uitvoeren.
Een van deze dingen is het maken van een nieuw inhoudstype (content type) dat overerft van de kalender lijst. Standaard kun je een mooie kalender lijst maken met al de benodigde velden, echter wilde ik hier een eigen inhoudstype bij maken. Ik begon op de normale manier, totdat ik er achter kwam dat je hier niet van kunt overerven. Het inhoudstype Event staat in de groep _Hidden waardoor je er niet bij kunt.
Na even zoeken op internet kwam ik uit op Will's Blog ( http://blogs.vertigo.com/personal/willa/Blog/archive/2007/04/25/calendar-content-types-in-sharepoint-2007.aspx ) die iets vergelijkbaars wilde doen als mij. Wat hij lijkt te doen is de groep _Hidden een andere naam geven, waardoor deze zichtbaar wordt en je dus van alle inhoudstypen in die lijst kunt gaan overerven. De acties die hij beschrijft zijn redelijk te volgen, maar echt ideaal is het niet, zeker niet om op een semi-productie omgeving te doen.
Nu kwam ik toevallig op een andere oplossing. Via de interface van Sharepoint kun je helemaal 'inzoomen' op het inhoudstype Event en uiteindelijk kun je deze ook gaan bewerken. Als je deze nou gaat bewerken kun je hem ook in een andere groep gaan opslaan. Zelf heb ik nu een groep aangemaakt met de naam Sharepoint verborgen en daar dit inhoudstype in geplaatst. Nu kan ik vanuit die groep nieuwe inhoudstypen maken die afleiden van de Event. Hier kwam ik achter omdat ik eerder al een keer de kolom Titel had hernoemd naar iets anders op eenzelfde manier.
Na deze 'spannende' actie kon ik verder met het afmaken van m'n kalender op de website die ik aan het maken was.
Onlangs vond ik het nodig of handig om C# code toe te kunnen voegen aan m'n eigen pagina's die in Sharepoint Designer waren aangemaakt. Dit heeft natuurlijk ook behoorlijk veel potentieel, aangezien je met C# enorm veel en krachtige dingen kunt doen. Omdat Sharepoint toch in het .Net Framework draait, moet dit ook mogelijk zijn vond ik.
Na nog geen 30 seconden kwam ik er achter dat dit niet triviaal was. Nadat je een code blok hebt toegevoegd (en uiteraard server-side code in uitvoert) krijg je een mooie melding in het scherm dat dit niet is toegestaan, iets in de trend als dit:

An error occurred during the processing of /Pages/test.aspx. Code blocks are not allowed in this file.

Ok, het plaatsen van code blokken is dus afgeschermd. Hier kan ik me wel iets bij voorstellen, aangezien het een enorm krachtige feature kan zijn die ook misbruikt kan worden. Toch moet zoiets mogelijk zijn vond ik. Nu had ik in de tussentijd al een work-around bedacht om toch geen code blokken te hoeven gebruiken, maar toch bleef dit in m'n achterhoofd rond dwalen. In m'n pauze heb ik even gezocht hoe je toch code toe kunt voegen in je eigen aspx-pagina's die je hebt gemaakt in Sharepoint Designer.

M'n vermoeden was juist, server-side code is standaard uitgeschakeld in Sharepoint pagina's. Om dit toch uit te kunnen voeren moet je de web.config aanpassen.
Wanneer je dit toevoegd in de web.config

<PageParserPaths>
<PageParserPath VirtualPath="/pages/custompagina.aspx" CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>

zou je server-side code uit moeten kunnen voeren in de custompagina.aspx. Ook kun je hier wildcards als een *-teken in gaan gebruiken, dus zul je waarschijnlijk ook iets als /*/*.aspx kunnen toevoegen om alle aspx-pagina's deze functionaliteit te geven. Let wel op wat je hier doet, aangezien het natuurlijk niet de bedoeling is om iedere pagina deze rechten te geven. Het is natuurlijk om een reden uitgeschakeld.
Zelf heb ik het nog niet geprobeerd, aangezien ik de web.config op dat moment niet aan kon passen en in de tussentijd al een andere work-around voor m'n pagina had bedacht. Voor een volgende keer ga ik dit zeker eens proberen.
Een van de onderdelen die ik onlangs heb moeten maken in een Sharepoint website zijn Infopath formulieren.
Het mooie van deze formulieren is dat ze redelijk gebruikersvriendelijk zijn en je ze in Sharepoint ook volledig kunt ontleden. We hadden gekozen om deze formulieren in een eigen venster (applicatie) op te starten en dat het formulier na indienen werd gesloten. Nadat het formulier wordt gesloten belandt je in de lijst van formulieren. Dit wil je als eindgebruiker natuurlijk niet zien, aangezien dat er veel te technisch uit ziet. Eigenlijk wil je dat je dan op een pagina komt met een melding dat het formulier is opgestuurd en het venster kan worden gesloten. We zagen hier echter geen mogelijkheid tot. Iedere keer dat ik het formulier opende en verstuurde was het een doorn in het oog dat die lijst werd getoond.
Plotseling zag ik iets in de hyperlink die het formulier aanriep. Hier werd namelijk de parameter Source in gestopt. De waarde van deze parameter was de locatie van de lijst met Infopath formulieren (wel helemaal ge-encode). Nu kon ik wel raden wat de parameter Source deed, maar toch voor de zekerheid heb ik deze even gewijzigd naar http://www.jan-v.nl (en niet ge-encode). Precies wat ik dacht er wordt naar deze source-url ge-redirect nadat je het formulier hebt verstuurd. Dat we eerst op de Infopath lijst uit kwamen was niet zo heel raar, aangezien we de link hadden gekopieerd van de Nieuw item-knop in de lijst.
De originele url was:

http://intranet/subsite/subsubsite/_layouts/FormServer.aspx?XsnLocation=http://intranet/subsite/subsubsite/InfopathLijst/Forms/template.xsn&SaveLocation=http%3A%2F%2Fintranet%2Fsubsite%2Fsubsubsite%2FInfopathLijst&Source=http%3A%2F%2Fintranet%2Fsubsite%2Fsubsubsite%2FInfopathLijst%2FForms%2FAllItems%2Easpx&DefaultItemOpen=1

en deze is nu gewijzigd om door te linken naar de eigengemaakte melding-pagina:

http://intranet/subsite/subsubsite/_layouts/FormServer.aspx?XsnLocation=http://intranet/subsite/subsubsite/InfopathLijst/Forms/template.xsn&SaveLocation=http%3A%2F%2Fintranet%2Fsubsite%2Fsubsubsite%2FInfopathLijst&Source=http://www.jan-v.nl/meldingpagina.html&DefaultItemOpen=1"

Eigenlijk is het wel een hele smerige oplossing naar mijn mening, maar in de tijd dat ik met Sharepoint bezig ben heb ik al lang door dat je hier soms niet omheen kunt en oplossingen soms tegen beter weten in moeten worden doorgevoerd.
Afgelopen weken hebben we het op het werk weer behoorlijk druk gehad met het maken van verschillende Sharepoint websites. Een van deze websites was een publieke site (dus het Internet). Dit is natuurlijk goed te doen, aangezien Sharepoint behoorlijk veel vrijheid biedt en er al veel onderdelen standaard in zitten.
Bij oplevering van deze specifieke website was iedereen blij met het resultaat, maar na 1 dag kwamen ze achter een klein probleem. Tijdens het testen en ontwikkelen hadden we de site onder een bepaalde hostheader geplaatst, laten we deze even http://website.bedrijf.nl noemen. Hier kon men de pagina's prima mee bekijken, bewerken, toevoegen en verwijderen. De website wordt echter aan het publiek getoond onder de hostheader http://www.website.nl. Het probleem op dit laatste adres is echter dat ze vanaf de klant hun werk locatie niet in kunnen loggen op de website. Aangezien de beide hostheaders naar dezelfde website verwijzen (via het uitbreiden van een sitecollectie), zijn er dus op zich geen kritieke problemen, maar echt fijn is het niet.
Het probleem zit hem in de proxy server of firewall bij de klant, deze blokkeert de verzoeken om in te kunnen loggen op de website (Windows inlogbox en NTLM). Dit werd bevestigd na een behoorlijke tijd te zoeken naar dit probleem, maar echte oplossingen hiervoor kon ik niet vinden.
Uiteindelijk las ik iets over Basisverificatie op websites. Dit houdt in dat er geen encryptie meer wordt plaatsgevonden op het wachtwoord en deze dus als plain-text wordt verstuurd. Dit is dus absoluut niet meer veilig en ook niet aan te raden op een productie omgeving, maar het houdt wel in dat de proxy server het inlogverzoek niet meer blokkeert.

Om zeker te zijn van m'n zaak heb ik dit dus eerst als test ingeschakeld (onder Toepassingsbeheer -> Verificatieproviders) en aan de klant gevraagd of ze in konden loggen via de uiteindelijke link http://www.website.nl. Dit bleek het geval te zijn en dus wist ik zeker dat Basisverificatie (Basic Authentication) echt gaat werken in dit geval. Nu moet er nog wel een SSL-certificaat worden geïnstalleerd, zodat het wachtwoord wel weer wordt versleuteld, of we moeten gebruik gaan maken van forms-authenticatie. Dat gaat volgens mij ook werken, maar nog niet uitgeprobeerd.
Dit krijgt zeker nog een vervolg, aangezien het nuttig is om te weten hoe dit op een correcte manier opgelost dient te worden. Momenteel ben ik namelijk niet echt tevreden, aangezien ik al heb gelezen dat de Verificatieproviders ook op hele andere manieren gebruikt kunnen worden wat mij persoonlijk beter lijkt. Dan krijg je namelijk een URL om de website te bekijken en een om te bewerken (via intern) en eventueel nog een url om als Intranet van dienst te kunnen doen.
Vandaag was ik druk met het maken van een custom pagina binnen Sharepoint. De bedoeling van deze pagina was om bulk-accorderingen te kunnen doen op Workflow taken. In dit geval was het namelijk best mogelijk dat je ineens een stuk of 10 (of meer) taken toegewezen had gekregen. Als je in 1 oogopslag al weet dat ze allemaal moeten worden goedgekeurd (of afgekeurd), dan wil je dit niet stuk voor stuk moeten afhandelen.
Nu had ik al een mooi stuk code geschreven om te achterhalen wat de taken in de lijst waren, maar hier moest ook nog een filter op komen, immers je wilt niet de reeds afgesloten (goedgekeurde, afgekeurde, beëindigde) workflows bewerken. Enige probleem dat ik ondervond was dat je in de CAML-query niet kon filteren op de tekst Voltooid of ieder ander passende status tekst.
Door wat slim te debuggen kwam ik er al snel achter dat de status met een ID wordt aangegeven. Op nagenoeg de eerste pagina die ik vond via Google stond een mooi lijstje met de status id's en bijbehorende teksten.


Status Value

Not Started 0
Failed on Start 1
In Progress 2
Error Occurred 3
Canceled 4
Completed 5
Failed on Start (retrying) 6
Error Occurred (retrying) 7
Canceled 15 * This is defined but I don't think this value is used
Approved 16
Rejected 17

Bron: http://www.sharepointblogs.com/dwise/archive/2006/12/11/howto-filter-a-view-based-on-workflow-status.aspx
Zo'n lijstje is natuurlijk altijd handig om te kunnen raadplegen. In mijn geval moest ik status 5 gebruiken, aangezien ik een kleine workflow had die alleen maar de status In progress of Completed kan krijgen (maar dan met de Nederlandse vertalingen uiteraard).
Bij ons op het werk hebben we een standaard virtuele pc die we kunnen inzetten voor verschillende doeleinden/klanten. Dit werkt perfect en is ook zeker aan te raden voor ontwikkel werkzaamheden met Sharepoint opdrachten.
Het nadeel van zo'n standaard image is dat de machine 1 naam heeft. Als alle ontwikkelaars dus zo'n machine opstarten, dan zijn er verschillende machines met dezelfde computernaam in het netwerk. In hoeverre het netwerk daar blij mee is weet ik niet, maar zelf vind ik het in ieder geval niet zo mooi.

Nu kun je heel eenvoudig de machine naam wijzigen via het Configuratiescherm, dat is dan ook geen probleem. Het probleem ligt echter in MS SQL Server. Wanneer de computernaam wijzigt, kan dit vervelende consequenties hebben voor SQL Server. Nu wil het toeval dat op deze standaard machine ook SQL Server staat geinstalleerd. Er was mij verteld dat het niet mogelijk is om de computernaam van de SQL Server te wijzigen en dat wanneer SQL Server eenmaal is geinstalleerd op de machine, je verder niet meer van dit soort rigoreuze systeemwijzingen moest gaan doorvoeren.
Eigenwijs als ik ben, ben ik op zoek gegaan naar een oplossing voor dit probleem. Ik vond het namelijk absurd dat je een computernaam niet meer mag wijzigen nadat SQL Server is geinstalleerd.
Mijn zoeken werd al snel beloond veel waarschuwingen, doemdenkers en gelukkig ook 1 oplossing.

Dit is namelijk wat je moet doen wanneer je de servernaam in SQL Server wilt wijzigen.

Ten eerste wijzig je uiteraard de naam van je server zelf in het Configuratiescherm.
Je zult nu waarschijnlijk de server moeten herstarten.
Nadat de server weer is opgestart, start je SQL Server Management Studio op (in het geval van SQL Server 2005).
Maak een query en controleer of de servernaam binnen SQL Server ook echt 'fout' is. Dit kan worden gedaan door het commando

select @@servername

uit te voeren.

Als resultaat zul je (hoogstwaarschijnlijk) de oude servernaam te zien krijgen.
Dit kun je wijzigen door het volgende commando's uit te voeren.
Eerst verwijder je de server door

sp_dropserver 'OUDESERVERNAAM'

uit te voeren en daarna voeg je een nieuwe server toe door dit commando uit te voeren:

sp_addserver 'NIEUWESERVERNAAM', local


Op dit moment ben je halverwege het proces, want de servernaam is nog niet direct verwerkt.
SQL Server zal eerst moeten worden herstart voordat deze wijziging wordt doorgevoerd.
Dit kan worden gedaan in de Command Prompt.
Voer gewoon de commando's

net stop mssqlserver

net start mssqlserver

achtereenvolgend uit.

Als je de query

select @@servername

nu weer uitvoert zie je dat de servernaam is gewijzigd.

De bron waar ik deze wijsheid vandaan heb is dit: http://blogs.techrepublic.com.com/datacenter/?p=192
Kudo'sStumble it!
Het is weer eens zo ver, ik heb me laten verleiden om weer een aankoop te doen die niet in m'n normale bestedingspatroon past. Zojuist heb ik in Kuinre bij Piaffe Ruitersport ( http://www.piafferuitersport.nl/ ) de basis attributen gekocht om te kunnen beginnen met rijden. Gisteren was ik al even langs m'n ouders gereden om te kijken of m'n oude spullen nog pastten, maar blijkbaar ben ik in de afgelopen 10 jaar toch iets gegroeid, of het materiaal is gekrompen op zolder. Hoe dan ook, met zo'n leuke extra vakantiebonus die ik heb mogen ontvangen kon dit er wel van af. De Lemster week viel qua kosten namelijk ook al enorm mee.
Op onderstaande foto's is het geheel te zien.
Zo heb ik nu een nieuwe cap, broek, 1 paar schoenen en 1 paar chaps aangeschaft.


Normaliter ben ik niet zo'n fan van chaps, maar deze vielen nog wel mee. Anders moesten er alweer leren laarzen worden gekocht en dan stijgt de prijs op het kassa bonnetje ook enorm. Die leren laarzen komen dus wel eens een andere keer, zodra ik het 'sporten' echt weer in de vingers begin te krijgen.

Die broek ik trouwens ook wel gaaf, daar zit bij het binnenbeen en je achterste wat steviger leer, zodat je beter in het zadel blijft zitten.
Voor de cap had ik eerst een andere in m'n handen, maar die zat minder lekker. Deze die ik nu heb was zo'n 100 euro goedkoper en zat lekkerder. Heel raar dus. Jammergenoeg wel minder ventilatie.

Ben benieuwd of het ook werkt op de baan. Voor de spiegel ziet het er in ieder geval wel leuk uit.