Jan-v.nl weblog
Sinds afgelopen week ben ik toch maar eens begonnen met de hype van dit en afgelopen jaar, Twitter.
Iedereen heeft het er continu over, zelfs bij Edwin Evers op 538 en nu was een collega van mij er ook aan begonnen. Eigenlijk vind ik het helemaal niets wat je er mee kunt. Het slaat ook helemaal nergens op als je het mij vraagt.
Nu heb ik zo'n 2 dagen een account en moet zeggen dat ik toch (nog) redelijk actief ben. Misschien juist omdat het nergens op slaat.
Ook heb ik nu al wat software geinstalleerd om sneller te kunnen 'Twitteren'. Zo heb ik in FireFox de add-in TwitterFox ( http://twitterfox.net/ ) geinstalleerd om zo via m'n Windows XP machine snel te kunnen reageren. Op m'n Vista machine heb ik Twadget ( http://arsecandle.org/twadget/ ) geinstalleerd om zo ook op m'n werk mee te kunnen doen.

Op zich is het wel een stuk leuker dan de Wie-Wat-Waar van Hyves, maar toch zie ik het licht nog niet echt. Ach, zo lang het nog geen kwaad kan ga ik er maar rustig mee door.

Je kunt me volgen op http://twitter.com/jan_de_v
Thuis heb ik een WHS machine staan en daar wil ik natuurlijk vanaf al m'n machines mee kunnen werken. Op dit moment is er Vista Business 64-bit geinstalleerd op m'n werk laptop en wilde ik daar dus ook de WHS Connector software op draaien.
Dit lukt standaard echter niet, omdat je dan een melding krijgt dat het niet op een 64-bit machine gedraaid kan worden.
Nu kun je dit omzeilen door het volgende in de command prompt in te tikken:

msiexec /i "\SERVER\Software\Home Server Connector Software\whsconnector.msi" WHSMSI="RUNSETUP"


De installer begint nu te draaien en voltooid verder ook zonder problemen. Ik heb gehoord dat het maken van backups niet gaat werken, maar in eerste instantie gaat het me ook alleen maar om het bestanden delen vanaf m'n werk laptop.
Toch vind ik wel dat er in een volgend Service Pack hier iets aan gedaan moet worden, of nog beter, een Homeserver 2008 64-bit maken. Maar ja, dat zal nog wel een paar jaar duren.
Met de komst van Microsoft Server 2008 waar de Hyper-V technologie in zit, heeft het bedrijf ook besloten om een gratis versie van deze server te maken, waar alleen Hyper-V in zit geïmplementeerd, dus geen grafische gebruikers interface. De gratis versie is op dit moment te downloaden via deze pagina: http://www.microsoft.com/servers/hyper-v-server/default.mspx.
Zelf heb ik deze server nu ook draaien op m’n thuisserver. Eerst had ik daar alleen Windows Home Server op draaien, maar nu dus een Hyper-V server met een virtuele WHS installatie. Het mooie van de Hyper-V server, is dat deze 64-bit is, in tegenstelling tot WHS die ‘gewoon’ 32-bit is. Met m’n installatie van de Hyper-V server kan ik het interne geheugen nu uitbreiden naar 10GB en er ook nog iets nuttigs mee doen in plaats van het 4GB limiet bij een 32-bit machine.

Na de installatie van de Hyper-V server stuitte ik nog wel op enkele problemen. Ik had zelf verwacht dat de server al klaar zou zijn voor externe verbindingen vanuit de Hyper-V Manager (speciale MMC plug-in voor deze server), maar niets is minder waar. Om gebruik de Hyper-V server te kunnen gebruiken zul je eerst via de prompt de Windows Firewall moeten configureren. Gelukkig ben ik niet de enige die dit probleem ondervond en was via internet wel het een en ander te vinden.

Als eerste is het noodzakelijk om de Management Tools van Windows Vista te downloaden. Deze zijn hier te vinden: http://support.microsoft.com/kb/952627.
Tijdens het downloaden kan de Hyper-V server gewoon worden geïnstalleerd, zoals je normaal ook zou doen bij een server. De initiele installatie is redelijk eenvoudig en komt eigenlijk neer op continu op Next te drukken.
Na de installatie kun je proberen de Hyper-V Manager op te starten. Bij het connectie maken naar de server zul je waarschijnlijk een melding krijgen als deze: Solving “Access denied. Unable to establish communication between: <Hyper-V Server> and <Vista client>”
Dit komt omdat de server nog niet is geconfigureerd voor externe connecties.
Wat ik heb gedaan is op de server een administrator account aanmaken met dezelfde credentials als die op jouw eigen systeem, zodat deze als eerste wordt verstuurd naar de server bij het inloggen in de Hyper-V Manager.
Nu is het tijd om de firewall regels toe te voegen. Je kunt dit toevoegen:
netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes
daarna het volgende
cscript windowssystem32scregedit.wsf /ar 0
cscript windowssystem32scregedit.wsf /cs 0

Hierna volgt een reboot van het system:
shutdown /t 0 /r

Nu zou de server goed moeten zijn geconfigureerd. Nu moet er nog in Vista wat worden gewijzigd.
Wanneer je de dcomcnfg opstart moet je onder Component Services -> Computers -> My Computer rechts klikken en de eigenschappen hiervan opvragen. Op het tabblad COM Security wijzigen we nu de Access Permission en geven we ANONYMOUS LOGON het recht Allow bij Remote Access.

Nu zou het mogelijk moeten zijn om de server te kunnen benaderen vanaf je eigen desktop.

Een tutorial die ik heb gebruikt bij de installaties is deze: http://blog.augustoalvarez.com.ar/2008/12/12/hyper-v-server-installing-configuring-and-troubleshooting/
Ook deze is handig, waar alles via een filmpje wordt uitgelegd: http://www.netometer.com/video/tutorials/manage-microsoft-hyper-v-server-remotely-workgroup-vista/

Al met al is het wel even puzzelen om je systeem aan de praat te krijgen, maar dat is het ook wel weer waard als je bezig gaat met de hyper-v virtualisatie. Volgens mij is deze gratis versie trouwens nagenoeg gelijk als de Core versie van Windows Server 2008.
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.