I like using the blank site template to create new sites. Most people tend to use the team site, but that already has a document library, calendar and a number of preactivated features. Nice to start a team site, but what if the site you’re creating is not a team site?? As I said; I like starting clean.

But amongst the features not being activated by default on a blank site is a tricky one: the TaxonomyStaplerFeature (ID 73EF14B1-13A9-416b-A9B5-ECECA2B0604C). This is a stapling feature which in it’s turn activates multiple other hidden features. You need it for several taxonomy related things, like subscribing to content types from an enterprise content hub. And as said; the features are hidden, so you can only enable them if you have server access.

So I guess we’ll need another stapling feature, to staple the missing features to the blank site definition!? I’m not sure yet if this is the only one which messes up pretty regular functionality. I don’t mind features I don’t use that often being off, but this one should have been on by default in my opinion. Or they could have provided another template: “blank site with no functionality whatsoever”.

Dat gedoe over sapstromen deed me denken aan iets wat me al een tijdje fascineert. Pisvrees. Voor de vrouwelijke lezers van mijn blog: daar hebben sommige mannen last van. Ik persoonlijk niet overigens, laten we dat voorop stellen. Als ik moet, dan moet ik; het zal me werkelijk een worst (hèhè…) wezen hoeveel man er dan naast of achter me staat. Een ieder van mijn mannelijke vrienden zal kunnen bevestigen dat ik probleemloos mijn fiere straal in de pot laat kletteren. Dat maakt het ook dat ik me lastig kan verplaatsen in het hele verschijnsel.

Van wat ik heb begrepen maakt de pisvrees het onmogelijk om je plas te lozen wanneer er andere kerels in de buurt zijn. En tja, op sommige toiletten is dat nu eenmaal zo. Zeker als de hokjes bezet zijn, of af en toe te smerig voor woorden. En daar sta je dan, met je volle blaas. Dat is dus precies het gedeelte wat ik niet zo snap. Als je moet en je gaat niet; dan pis na een tijdje toch in je broek? Lijkt me toch net ietsjes genanter.

Begrijp me niet verkeerd: het lijkt me super vervelend, ik heb het te doen met de mannen die hier onder gebukt gaan. Iedere keer in spanning naar het toilet, hopend op een leeg en fris hokje. En ik vraag me meteen af: werkt het in een hokje dan wel meteen? Wat nu als het hokje naast je bezet is en de tijdelijke eigenaar van die twee vierkante meter grond er wat geluid bij maakt? Lastig.

En nu ik er zo over mijmer vraag ik me af of vrouwen hier überhaupt wel eens last van hebben!? Ik bedoel; die gebruiken nooit een urinoir of goot. Altijd in een hokje. Dus bestaat er wel zoiets als vrouwelijke pisvrees? Wat een raadsels.

Een hoop van onze gewoonten en gedragen zijn op een of andere manier terug te herleiden naar “de oermens”. Ons sociale gedrag, het “bij de groep willen horen”; dat doe je omdat je vroeger als eenling ten dode opgeschreven was. Voer voor de leeuwen. Maar wat dan als je buiten de groep, ergens achteraf je plas moet doen? Ga er maar aan staan! We mogen dus wel concluderen dat deze mannen eigenlijk de echte bikkels zijn. Niks om mee te spotten! En verder: succes.

Let’s sum up the things we’ll need to get this working:

1. An ADFS server is required to validate the authentication requests. This server needs to be accessible via the Internet, so usually it will live inside a DMZ zone of some kind. Let me clarify that I am not an authentication / ADFS expert and that I did not configure our sever (actually, I don’t even have access). So you might need the help of a colleague here as I did.
2. You need to setup Azures ACS (Access Control Service). How to do that, I will describe in this article.
3. You need to alter your client and server code to authenticate themselves using ADFS instead of the previously used shared access key.

The authentication flow will go as follows:

1. Your client sends an authentication request to the ADFS server.
2. The ADFS server replies with a SAML token when the credentials supplied were valid. This token is encrypted.
3. Your client decrypts the token using the decryption certificate.
4. The decrypted token is used to create a TokenProvider object, which is then passed to the relay binding endpoint.
5. Because of the trust setup between ACS and ADFS, ACS will recognized the passed along token and provide access based on it.

Behind the scenes there’s much more going on, but these are the basics. This differs from what I first had in mind myself; I thought ACS would contact ADFS and handle the security. It’s important to realize it doesn’t work that way; YOU need to provide the ADFS token. Perhaps they’ll change that in de future? Don’t know. It would be great if you could just send credentials to ACS and tell it to verify them at the ADFS server. But until that happens, this is what you’ll need to do.

ADFS Requirements

First, we’re going to setup ADFS. I’m going to assume you’ll won’t be doing that yourself (I didn’t). If you’re going to contact your ADFS administrator, you’ll need the following things:

• The URL of the FederationMetadata.xml. This is usually found at:
  https://adfs.company.com/FederationMetadata/2007-06/FederationMetadata.xmlThese XML’s are great because they automate a part of the setup.
• The token decryption certificate
  Which you’ll need to decrypt the token (duh), otherwise you won’t be able to use it.
  
• His ok to configure a relying party
  The administrator will need to configure ACS as a relying party in ADFS as well. Sure make sure you get the approvals for that when needed.
  
• Enabled usernamemixed endpoint
  Ask the administrator to verify that the usernamemixed endpoint is enabled and ask for the URL. Normally it would be:
  https://adfs.company.com/adfs/services/trust/13/usernamemixed

In return, you can provide the ADFS administrator with the metadata XML URL for ACS. He can use that to configure a relying party in ADFS. The URL is found in the ACS management portal, under “Application Development”. It will be something like: https://calculator-sb.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml.
Note: you’ll need the –sb URL (also see “Setting up ACS”)!

Setting up ADFS

I’m not going to elaborate on how to setup ADFS since I’m not a specialist. I can however point you to this article: http://msdn.microsoft.com/en-us/library/jj136813.aspx. It clearly describes what to do. I used it as guidance on this entire project, but it doesn’t use username/password type credentials, so don’t copy/paste the code!

Setting up ACS

Setting up ACS is described in the article as well, but I want to elaborate on that a bit. First important thing to realize is that your service bus has a separate ACS! That fooled me for a while; I would open up the Azure management portal, click Active Directory, select my instance and select “Manage”. But in that case, Service Bus won’t be there as a relying party! To open up the correct one, go to “Service Bus”, click “Access Key” and then click the “Open ACS Management Portal” link. Or you can browse to “https://namespace-sb.accesscontrol.windows.net“, replace namespace with your own of course.

If your ADFS administrator gave you the FederationMetadata URL, setting up is easy.

• Click “Identity Providers”
• Select “WS-Federation identity provider”
• Choose a name and insert the metadata URL
• Under “Used by” select “Service Bus”. This will hook up this identity provider to the service bus.

Done! Using the metadata from the XML, the rest is configured pretty much automagically. Again, for more detail check out this article.

Setting up the client and server

Now it’s back to code again. For both the server and the client, we will have to switch out the TokenProvider. In the relay example we were using TokenProvider.CreateSharedSecretTokenProvider, now we will use TokenProvider.CreateSamlTokenProvider instead. For that, we’ll need a SAML token which we will get from ADFS.

The samples are a bit too big to all publish, so please just download the solution file (see bottom). I will highlight a few things.

• For connecting to the ADFS instance, we use the UserNameWSTrustBinding binding.
• That binding is used in a WSTrustChannelFactory instance, in which we need to set the credentials of the user. Note that for both client and server it doesn’t matter what you put in here, as long as the account is a valid one. But you can implement more control later, requesting certain claims for instance. I need to figure out how before I blog about it
• Another thing to note is the value we put into the “AppliesTo” property of the RequestSecurityToken. The value needs to be present in the “relying party identifiers” list of ADFS. If it’s not, you’ll won’t receive a token.

So that all boils down to:

string samlToken = GetTokenFromADFS.GetIssuedToken(Constants.adfsTrust13UsernameMixed, Constants.acsEndpoint, Constants.adfsX509CertificateSubjectName, Constants.domainUser, Constants.domainPassword);

var cf = new ChannelFactory<ICalculatorChannel>(
             new BasicHttpRelayBinding(),
             new EndpointAddress(ServiceBusEnvironment.CreateServiceUri("https", Constants.sbNamespace, Constants.sbServicePath)));

cf.Endpoint.Behaviors.Add(new
    TransportClientEndpointBehavior {
        TokenProvider = TokenProvider.CreateSamlTokenProvider(samlToken)
});

To be absolutely honest, the GetTokenFromADFS.GetIssuedToken
I mostly got from a very kind Microsoft engineer who helped me on this. If you want to create and understand that yourself, you got some reading to do about the authentication flow (spnego). I just know it works and have a general understanding of what it does. That suffices too

By the way, Microsoft guys, why not stick a method like GetTokenFromADFS.GetIssuedToken in the IdentityProvider framework dll’s?

As you can see, the code is not that different from what it was. And that’s the beauty of it. Apart from the “fetch SAML token” code, most stuff is done by the Azure ServiceBus SDK bits. So once you understand the trick, it’s easy to implement, also for existing WCF services you might want to expose.

And then… finally… here’s the code! Make sure you alter the values in constants.cs (shared) and eventually create a configuration file of course.

http://sdrv.ms/16YCt54

Hope you like it (and it works). If not, please use the comments below!

• Create a WCF webservice to host the data.
• Deploy the webservice into some kind of secured network zone (DMZ).
• Kindly ask the firewall admins to open up a port to your service.
• Register a DNS address which makes it easier to call your service.
• Request SSL certificates and secure your service so only encrypted data is sent.

In this article, I’ll write about how Azure can make your life easier by handling some of these things in a different way. You, as a reader, should be familiar with WCF and have a basic understanding of authentication schemes. Some knowledge of what ADFS is would be handy too.

There’s two Azure topics I want to talk about: relay and ACS. In the first part of this article, we’ll talk about relay. How to setup ACS with ADFS will be topic of the second part.

Setting up the service bus in Azure

Relay is a technique which enables you to register your WCF service with Azure. Once registered, clients are able to call Azure instead of your service directly. And because the service initiates the communication, you only need access to the Internet, not from it. In Azure, this is handled by the service bus, which is a multifunctional messaging system. Relay is only a part of the functionality.

Here’s what happens in general:

1. The service registers itself with Azure .
2. Azure acknowledges the registration. The connection is kept open for future use.
3. A client now connects to the endpoint registered with Azure and sends a webservice request.
4. The request is relayed to the local WCF service.
5. The result is passed back to Azure.
6. The service bus passes the result to the client.

For you as a developer, this has some advantages:

• The call to Azure is https secured, so all data going to Azure is always encrypted. No need to purchase an SSL certificate.
• Same goes for data going to the client, encrypted as well.
• No need to open up any firewall ports. Default internet access is enough to make this work
• Although I haven’t thoroughly tested this, it should work in all kinds of proxy-enabled scenario’s too.

Ok, cool. So what do you need to make this work? To begin with, you’ll need a Windows Azure account. Open up the management portal (https://manage.windowsazure.com/) and go to the “service bus” section. Click “Create” and choose a namespace for your service bus instance:

You can request the access key once you created the service bus instance. This key is used to authenticate server / client with the service bus. In part 2, we’re going to use ACS / ADFS for that, in which case the shared secret access key is irrelevant.

Creating a relayed WCF service

Once you’ve got your service bus namespace setup, it’s time to create a service. Most easy way is to create a console application which will use a ServiceHost object to self-host the service. The most important thing here are the bindings. You will have to use two bindings:

• One normal binding (like BasicHttpBinding) which hosts the service in a normal way, for instance on http://localhost:1234.
• A matching relay binding (in this case BasicHttpRelayBinding) which is used to connect to Azure and relay the service.

Assuming some WCF knowledge, creating a service host should be easy:

ServiceHost serviceHost = new ServiceHost(typeof(CalculatorAPI), new Uri(serviceEndpoint));

Registering the endpoints and bindings:

serviceHost.AddServiceEndpoint(
  typeof(ICalculatorAPI), new
  BasicHttpBinding(), "/"
);

serviceHost.AddServiceEndpoint(
    typeof(ICalculatorAPI), new BasicHttpRelayBinding(
        EndToEndBasicHttpSecurityMode.None, 
        RelayClientAuthenticationType.None),
    ServiceBusEnvironment.CreateServiceUri("https", "calculator", "api"))
    .Behaviors.Add(new TransportClientEndpointBehavior
    {
        TokenProvider = TokenProvider.CreateSharedSecretTokenProvider("owner", "<<azure_access_key>>")
    });

The things to notice:

• The bindings need to match. So use a BasicHttpRelayBinding in combination with a BasicHttpBinding and not a WsHttpBinding for instance.
• Both endpoints register the same interface class, so both endpoints know which methods your service will provide.
• For the relay binding, you specify the service bus address with the help of the CreateServiceUri method. This asks for a scheme, the namespace you created earlier and a service path which can be anything you like.

In the example for part 2 (ADFS), we’ll switch from using a SharedSecretTokenProvider to a SamlTokenProvider used with SAML tokens.

Basically, that’s all you need to do on the server side. Simple, right? You could create one extra endpoint to provide a mex metadata exchange binding. The code to do that:

// Check to see if the service host already has a ServiceMetadataBehavior
ServiceMetadataBehavior smb = serviceHost.Description.Behaviors.Find<ServiceMetadataBehavior>();

// If not, add one
if (smb == null)
  smb = new ServiceMetadataBehavior();

smb.HttpGetEnabled = true;
smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15;
serviceHost.Description.Behaviors.Add(smb);

// Add MEX endpoint
serviceHost.AddServiceEndpoint(
    ServiceMetadataBehavior.MexContractName,
    MetadataExchangeBindings.CreateMexHttpBinding(),
    serviceAddress + "/mex"
);

I would advise to use the mex endpoint only in development environments and leave it out for production. But that’s up to you, it doesn’t really matter that much.

Add a serviceHost.Open(), run your console app and see if it properly registers itself with Azure. Once it does, you should be able to create a client and connect with it.

Creating a client to match

Creating a client follows the same principles. The client counterpart of a ServiceHost is the ChannelFactory. Because it shares the interface definition, it’s wise to keep that class in a shared library. But you could also make use of the local endpoint and the “Add Service Reference” functionality of Visual Studio, which will generate an interface class for you. As long as the interface class has the same methods and signatures as your service has, you’re good.

var cf = new ChannelFactory<ICalculatorAPIChannel>(
    new BasicHttpRelayBinding(),
    new EndpointAddress(ServiceBusEnvironment.CreateServiceUri("https", "calculator", "api")));

Now, as we did with the service, we need to specify the endpoint behaviour:

cf.Endpoint.Behaviors.Add(
    new TransportClientEndpointBehavior {
        TokenProvider = TokenProvider.CreateSharedSecretTokenProvider("owner", "<<azure_access_key>>")
    });

And with that setup, you can simply create a channel and call the method of choice!

using (var ch = cf.CreateChannel())
{
    var answer = ch.Add(10, 6);
    Console.WriteLine("Answer: {0}", answer);
}

So the cool thing is, apart from some configuration and setup, it’s really not that hard to setup a relayed service. In my opinion, this is far less complicated than convincing the firewall guys to open up ports for you

This service is secure. All the communications are encrypted via SSL and both client and server need to know the shared access key to be able to connect to the service bus. But this method of authentication is pretty limited and not really usable in mobile apps scenario’s (how do you prevent some unauthorized user from using the app?). So in the follow-up of this article I will explain how to extend the sample with ADFS integrated authentication. That article will also contain a full code sample.

Update: and here’s part two.

When you’re building an installer for Windows Service, you might get stuck in the situation where the installer is deploying your files onto the filesystem, but the actual service isn’t appearing in the services console. That’s because the installer class didn’t get called to register the service. For those of you who don’t know; you need to add an installer class to your service which registers it with Windows (you can easily do so by right clicking the service and choosing “Add installer”.

Anyways. If this is the case, go to “Files” in step 2 of the installer and open it up. Right click your project and open up the properties window. Go to the second tab “COM & .NET Settings”.

There, you’ll find a checkbox “Installer Class” which you need to enable. Now compile your installer again and there you go: it’ll register your service in Windows again.

But content deployment is a tricky process in which a number of things can go wrong. Most of the solution I’m going to mention are not new, but I could not find a blog which combines them all, so that’s wat I did.

Object already exists

A common problem are errors telling you that stuff already exists on the target site. I found it a best practice to always start with an empty site. When you manually create two sites in seperate farms and then try content deployment, these errors are pretty likely to occur.

When you want to start with an empty site in your target environment, start with an empty site, not one based on the “blank site” template, because that one isn’t empty at all. To start with a truly empty site, navigate to Create Site Collection in Central Administration. For the template, choose custom and then the “<choose template later>” option. Technically, this will create your site collection, but leave the RootWeb empty for later specification. When you open your site in the browser, the first thing it will do is ask you which template you want to use. The point here: don’t choose one! Leave it empty before trying content deployment.

You might read this and think “hmmm, I didn’t do that”. You delete your existing site and try again. Same error? Reason for that is that deleting isn’t actually deleting. When you delete your site from Central Administration, it get’s marked for deletion in the database, but isn’t actually deleted. Reading blogs you’ll find the tip to run the Gradual Site Deletion timer job for your web application, which should delete the site. Well guess what; it doesn’t! That’s because your site remain undeleted for the period of time you’ve set your recycle bin settings to. By default that’s 30 days. After that, the content will be marked for deletion and the timer job will delete your site.

To force deletion, you can use the Remove-SPDeletedSite Powershell command. To find out the ID of the site (which I prefer to the relative URL), you can check the AllSites and AllWebs database tables.

After running the command, execute the timer job again and you’ll notice the rows in the database are really gone.

Feature not found

Ok, so you’ve now got your empty site, but deployment still fails. It complains about missing features.

When you deploy accross multiple farms, you need to check if the same features (mostly in WSP files) have been deployed to all farms. Upon deployment, SharePoint will check if everything needed is available in the target environment and give you errors if that’s not the case.

When you’ve checked that, there’s also the case of application servers and front-end servers. Your farm might have been setup so that the web applications are only deployed to the front-end servers and not the applications servers. Upon deployment of a solution, SharePoint deploys the feature files only to the servers actually running the web applications where the solution is being deployed to. So those feature files might not exist on your application server.

So you should check if you’re running content deployment on a server which has the files needed. Check if the feature listed as missing is present in the FEATURES folder of the SharePoint hyve.

When the content deployment configuration doesn’t list a front-end as an option, it’s likely that your front-ends are not running the “Central Administration” service. Start that service on one of your front-ends and you’ll be able to configure it for content deployment. Or make sure the features are deployed to the application server as well, that’s your choice.

Got any other common issues with content deployment? Put them in the comments!

Ik weeg m’n keuzes dan ook altijd goed af. Er wordt vooronderzoek gedaan op internet, waar ik zowel kijk naar de professionele reviews als gebruikerservaringen. Daar laat ik me meestal grotendeels door leiden, ik vind dat meer waard dan het verkooppraatje wat een verkoper in de winkel me kan vertellen. Natuurlijk, die hebben misschien verstand van zaken en zijn dagelijks met die spullen bezig. Maar toch; ze staan daar om je iets te verkopen. Omzet, dat is waar het onderaan de streep om draait.

Bij sommige beslissingen komt het onderbuik gevoel kijken, je kent het vast. Soms is dat gevoel positief, je beslissing “voelt” gewoon goed. En soms werkt het tegen je, denk je dagenlang nog “heb ik daar nu wel goed aan gedaan”. Dat laatste gevoel heb ik bij de aankoop van mijn was/droog combinatie. Door vele mensen afgeraden, toch gedaan. En of ik er goed aan heb gedaan, dat zal de tijd leren. Als je dat onderwerp interessant vindt, trouwens, lees dan vooral het boek “Start with why” van Simon Sinek, waarin wordt uitgelegd waarom beslissingen soms goed of juist niet goed voelen. Aanrader!

Goed, op naar de moraal van dit verhaal: een beslissing is meer dan alleen het afwegen van de positieve en negatieve punten. Er komt gevoel bij kijken en in sommige gevallen spelen er aan de zijkant nog allerlei belangen. Zo koop je waarschijnlijk eerder een fiets van je oom die een fietsenwinkel heeft, dan van een willekeurige andere fietsenboer. Niet omdat die fietsen nu per se beter of goedkoper zijn, maar omdat het je oom is. Is dat dan goed of slecht? Geen idee, maar het voelt als de juiste beslissing.

Toch proberen we in Nederland (en in de EU en daarbuiten net zo goed) kostte wat kost alle niet rationele overwegingen bij een aankoop zoveel mogelijk buitenspel te zeggen. En dan noemen we dat vervolgens: de aanbesteding. Het idee achter een aanbesteding is eenvoudig: je zet op papier wat je wilt hebben, laat aanbieders je daarop een voorstel doen en kiest vervolgens “de beste”. Maar is dat dan ook echt de beste? Stel dat 2 aanbieders beweren dat ze je exact hetzelfde kunnen leveren, maar aanbieder A) is 20% goedkoper. Op basis van de rationele feiten zou je zeggen: doen! Op basis van je onderbuik gevoel misschien niet?

Die aanbestedingen doen we niet omdat we daar zin in hebben, die doen we omdat het moet. Nog voor de aanvraag de deur uit gaat is het al geen vrije beslissing meer. Weg onderbuikgevoel. En dus zitten we nu met, ik noem maar wat, een Fyra die niet rijdt. Die voldeed op papier aan alle eisen en was goedkoper dan de concurrentie. Maar ja, die eisenlijst is altijd op meerdere manier te interpreteren. En wie zegt dat die gekke Italianen niet een paar vinkjes hebben gezet in kolommetjes, waar ze eigenlijk geen vinkje hadden mogen zetten? Vraag me af welke beslissing er genomen was wanneer de NS naar haar onderbuikgevoel had geluisterd.

Today I published my first Codeplex project. It’s called “Auto SP Solution Installer”, based upon the well known “Auto SP Installer” from which I borrowed some code.

The goal of the project is to easy the deployment process of solutions across farms in a DTAP environment. At a lot of my customers, I notice there’s a lack of SharePoint knowledge at the administration side. The administrators sometimes barely know what they’re doing, or they’re just doing what they are told by the developers. Or even worse: the developers are deploying stuff themselves.

Let’s be honest: the Auto SP Solution Installer can’t fix a faulty lifecycle process. But it can automate some of the steps, making sure the room for error get’s smaller.

The current feature set is as follows:

• Adding, removing, installing and updating your WSP files
• Deploying WSP’s to specific web applications
• Scheduled deployment of WSPs to prevent downtime
• Warning the farm administrator about maintenance compliancy and GAC deployments
• Installing, uninstalling, enabling and disabling features (scoped)
• Using the same deployment configuration across all your farms in a DTAP environment. Farm configuration is seperated from solution configuration.

Basically, you create a deployment configuration (XML) and provide some WSP’s. In a seperate configuration file, the farms (yes, multiple) are described. The script figures out on which farm it’s running, which web applications exist, etc.  and then deploys your solutions as configured. The same package of WSPs and config XML can then be moved to the next farm (test, acceptance, production) and re-used there without changing anything.

Also, the script will warn the administrator about maintenance windows and GAC deployments which will cause downtime to all of your web applications (IIS reset).

Interested? The first initial release can be found on Codeplex: http://autospsolinstaller.codeplex.com

Het verhaal is heel eenvoudig. Fabrikanten geven allerlei schitterende cijfers op voor hun zuinige modellen. Met deze auto’s draagt u een steentje bij, wordt de aarde een beetje groener, dat soort onzin. De overheid wil graag dat wij om het milieu denken en heeft daarom allerlei belastingvoordeelregeltjes bedacht voor mensen die graag in een Prius stappen. Ik zou er persoonlijk nog niet dood in gevonden willen worden, maar dat terzijde. Ik zou sowieso niet graag dood gevonden worden, ook dat terzijde.

En nu (en al eerder blijkbaar dus ook) blijkt dat die ‘groene’ rijders helemaal niet de verbruikscijfers halen die door de fabrikant zijn opgegeven. Joh! Tot zover nog niks nieuws onder de zon zou je zeggen. Zou je zeggen, want blijkbaar is Den Haag hier wel heel verbaasd over. Er wordt nu ineens gevraagd om nieuwe tests.

Hoi mensen in Den Haag. Ik heb alvast een nieuwe test bedacht. Vraag aan de leasemaatschappijen de kilometerstanden en de getankte liters brandstof op. Deel het een door het ander, dan weet je precies wat een auto verbruikt. Bereken zo per maand of jaar het bijtellingspercentage en beloon de zuinige rijder. De rijder die zijn best doet om netjes te rijden en weinig brandstof te verbruiken. En niet de rijder die kiest voor de leukste cijfertjes in de folder. Als u mij voor dit briljante idee mocht willen sponsoren met een leuk bijtellingstarief, mijn gegevens zijn reeds bij u bekend.

Ik hoop dat ze die belastingvoordeeltjes met terugwerkende kracht terugdraaien. En dan vooral voor de Prius rijder die mij met 150 voorbij komt stuiven op de snelweg. Dat zijn vast dezelfde mensen die zo geirriteerd zijn om de Grieken en hun belasting-ontduik-fratsen. Maar ondertussen wel 14% bijtelling aftikken voor een auto die op die manier geen steek zuiniger is dan een normaal model. En lelijk.

Vanaf het moment dat je naar je sollicitatie gaat is meteen wel duidelijk dat dit wel even iets anders is. In mijn geval mocht ik naar de HighTech campus in Eindhoven, wat sowieso al een toffe en inspirerende omgeving is. Er zitten daar veel tech bedrijven, namen waarvan je meteen denkt: “Hey! Ken ik!”. Een goed begin dus. De sollicitatie procedure was eigenlijk heel eenvoudig. Geen tests ofzo, gewoon twee gesprekjes en babbelen over je CV en ambities.

Eenmaal aangenomen begin je met (in mijn geval) 2 introductiedagen. De eerste dag krijg je, naast een stuk of 40 andere collega’s (wederom: in mijn geval, dat aantal schijnt te wisselen), meteen je toegangspas, laptop, SIM-kaart, VPN token, noem het maar op. De vrijdag ervoor had ik m’n pouleauto al voor de deur staan, werd bezorgd. Luxe! Tijdens de introductiedagen krijg je te horen hoe het bedrijf in elkaar zit, welke onderdelen er zijn en wat die doen. Ook wat er van je verwacht wordt; hoe je je uren inboekt, waar je e-learning modules kunt volgen, noem maar op. 2 Dagen volop informatie waarvan niet alles blijft hangen, maar het is een goed begin. En nog steeds kom ik soms collega’s tegen van “de intro”, lachen!

En dan aan de slag. De eerste dagen krijg je een buddy toegewezen die je wegwijs moet maken binnen het bedrijf. Daar kun je terecht met vragen, handig. Je gaat je Atos profiel maken zodat je aangeboden kunt worden aan klanten (afhankelijk van je functie natuurlijk). Even uitzoeken welke telefoon je wilt kopen van je budget in de phoneshop. Kortom: meteen onderweg. Netwerken is belangrijk, je collega’s wijzen je al snel op de koffieautomaat (hoewel ons nieuwe Enterprise Social Network deze snel moet gaan vervangen). Laat je zien en zorg dat mensen weten dat je openstaat voor opdrachten.

En dan het dagelijkse werken. Thuiswerken? Graag! De kantoorlocaties zijn beperkt, dus thuiswerken is geen vraag maar een must. Samenwerken doe je ook veel online. En soms face-to-face, bijvoorbeeld op ‘t Flight Forum in Eindhoven of in Utrecht. Dus ja, ik zit snel een uurtje in de auto om ergens te komen. Maar ook dat valt helemaal niet tegen. Gewoon op tijd weg (wel vroeg opstaan) maar vaak al voor 6 uur weer thuis. Dat lukte me bij mijn vorige baan nooit.

En er gebeurd echt vanalles! Zo hebben we een App Academy waar smartphone / tablet apps ontwikkelt worden. We hebben het Enterprise Social Network waar ik al over vertelde; een soort Facebook voor bedrijven. We hebben communities over allerlei onderwerpen waar je je voor kunt inschrijven. Die organiseren weer vaak (avond) sessies waar je veel van opsteekt. Weet je iets even niet zelf? Dan is de kans groot dat een collega je kan en wil helpen. En eigen initiatieven worden gewaardeerd! Dus ben ik nu community lead voor SharePoint, waardoor ik regelmatig online meetings heb met mensen uit Duitsland, Frankrijk en zelfs China. Boven het maaiveld uitsteken en opvallen in de menigte kan niet bij een groot bedrijf? Onzin. Tenminste, bij Atos dan.

Dus ja, ik zit wel op mijn plek! Mijn huidige opdracht loopt nog tot eind februari en dan gaan we weer kijken naar een nieuwe. En als het goed is ga ik nog ergens mijn best doen om de master opleiding voor SharePoint te volgen. Met misschien wel een tripje naar Redmond in het verschiet.

Werken bij een groot bedrijf? Doen!

Oh en ik moet er natuurlijk bij vermelden: als je interesse gewekt is, neem dan gerust contact op met me (jasper.siegmund@atos.net). Dan zorg ik dat je gegevens terecht komen bij recruitment. Of als je zelf contact opneemt, noem dan even mijn naam. Kan ik weer een leuk weekendje weg boeken