• Joining 2ToLead

    Big step for me during this 2016 celebrations season as I decided to leave Negotium for 2ToLead

    Good Bye Negotium

    Since I joined AlphaMosaik more than four years ago (I originally joined only for 18 months huh…), by the acquisition by Negotium and up to this day my working environment and the company I was part of changed a lot.

    This company allowed me to maturate and to learn a lot on cultural, personal and professional aspects. I’d like to take this opportunity to thank everybody I had the occasion to work with during this period of time.

    Hello 2ToLead

    I’m joining a young, innovating, fast growing company as a “Office 365 and Azure developer”. I’ll be lucky enough to work with brilliant people I met within the communities.

    These guys are just impressive, whitepapers with tens of thousands downloads, sessions at Ignite, fast growing… I hope I’m going to be up to speed.

    I’ll be the 3rd MVP to join the company also composed of former MSFT’s.

    Beyond my direct technical expertise, I’d like my new family to benefit from my knowledge around devops processes.

    See you soon, and thank you for being this many to read me.

    • 23/12/2016
  • Troubleshooting load balancing issues with SharePoint

    A few weeks ago, I’ve had to get hands on a customer’s SharePoint farm showing performance problems. They also had inconsistencies with display data between multiple calls.

    I quickly suspected a configuration issue for the load balancer dispatching calls between the front-end servers. However, I only had access to the SharePoint farm and I had to provide data so the network team so they could start investigating.

    Hence the question: how can we determine which server served the request between multiple calls?

    Most of the content out there suggests adding a text file containing the server’s name to the root of the web application. I’m not a big fan of this situation for multiple reasons:

    -          Adding/deleting files to SharePoint’s content is not something to do without being cautious, especially if you don’t know SharePoint very well.

    -          You can have cases, depending on the load balancer’s configuration (and especially if it’s not configured properly), that a server answers to one request and another one to the next one in subsequent calls. You have to determine which server has served each request.

    Obviously I didn’t try solutions like “deploy this custom solution and add that custom web part which is going to tell you which server is doing what”.

    I decided to add a Http response header that the server is going to send over with each request.

    The only downside of that solution is that it’s that setting up the header will recycle the application pool, causing a service interruption.

    To setup the header go to the IIS management console and select the web application you’re working with.

    Click on “http response headers”

    Add a new entry giving the name you want and the server name as the value.

    (repeat those steps for each server of the farm)

    Using any browser, open developer tools (most likely pressing F12), enable requests tracing and go to the response’s headers of any request. You’ll see your header with the name of the server as the value.

    Once you’re done troubleshooting, don’t forget to remove the header for two reasons:

    -          Http headers, before Http2 (which as of today is far from being widely implemented), are not being compressed which will increase network traffic.

    -          For security reasons, it’s never good to expose your server’s names.


    Have fun troubleshooting your load balancers.

    • 13/12/2016