List Lookup Control filtering in Nintex Forms not working

List Lookup control filtering in Nintex Forms is one of the more interesting features of this control because it gives you the ability to filter the values based on the value of another control and create cascading dropdowns. But this is also where it can go wrong at times.

Consider the following scenario… you have a SharePoint 2019 site running under the /sites managed path in a web application and there you have 3 lists:

  • User Access Requests: your main list where your Nintex Form will be used as a list form.
  • UARCountries: A simple list with a title column that is used as a lookup list in your form and contains countries.
  • UARRegions: A simple list with a title column and a country lookup column towards the UARCountries list.

On your main list, you have a Nintex form that has 2 List Lookup controls.

List Lookup Control filtering 1

The Country lookup list is configured as a normal list lookup. It pulls the countries from the UARCountries list.

List Lookup Control filtering 2

The Region lookup is configured to pull the regions from the UARRegions list.

List Lookup Control filtering 3

But we also configured a filter on this lookup because we only want to see the regions of the selected country in the Countries dropdown. For that, we applied a filter based on a control value.

List Lookup Control filtering 4

When you publish this form or just preview it, you would expect this to work. And in a lot of cases it is going to work. But not always.

I was in a situation where the Region dropdown was completely disabled when the form opened.

List Lookup Control filtering 5

And when I selected a country, the control was still in a disabled state.

List Lookup Control filtering 6

I started experimenting with this and started playing around with configuration changes for the control and noticed some things.

In the ULS, the following error messages were logged when the form was opened.

List Lookup Control filtering 7
List Lookup Control filtering 8

When I removed the filtering from the regions and just displayed all of them, the errors went away and all of the regions were displayed. So, the list was definately there…

Because this didn’t make any sense, I decided to take this to Nintex Support. They suggested upgrading to the latest version of Nintex Forms (v5.1.2). That didn’t help.
Then I found a post on the Nintex Community where the same errors were discussed in the context of list lookup control filtering.

Somebody posted a possible cause… the absence of a root site collection in the web application.

And sure enough… my web application didn’t have a root site collection. I only had sites running under /sites/…

I created a site in the root of the web application. Reopened my form and there you go… it worked!!

List Lookup Control filtering 9

The Region control was no longer disabled and the values were filtered as expected.

Being a consultant at CTG for 17,5 years…

Being a consultant at CTG for 17,5 years…

Yesterday, we had a team meeting at work and Jochen, our unit manager, had a great idea. Why not tell the public how much you like your company. This is indeed something we should do more often.  He put his money where his mouth was, and did it live on LinkedIn.

I’m going to do it my way… this will end up on LinkedIn anyway 🙂

What does CTG mean to me? Well, obviously a lot, because I have been working there for the last 17,5 years. I have seen many colleagues come and go but I always stayed put and believed in them. Why? There are a lot of reasons, but the main reason is the way they treat their people.
A lot of organizations show off with fancy certifications and awards and you can (and should) be sceptical about these things. CTG also has some… we have been part of The Best Workplaces in Belgium for many years. We have been Investor in People for a long time.

Every year, on my career appraisal, my manager asks the same question… Are you still happy at CTG? And I always respond with the same thing:
If I get to a point where I go to work unhappy, I quit. It’s a simple as that. And this is something I literally mean.

So, what makes me so happy at CTG? It’s a combination of things.
The culture is one thing. We have a very open culture.
In my long career as a consultant, I talked to a lot of people and it amazes me how many organizations are out there that have a culture where people work against each other as part of internal politics and internal competition. I can’t imagine myself working in such an environment. And this is what I like about CTG. People are not working for their customers and their personal gain. They are working for OUR customers and to grow on a personal level but also to grow and mature the company.
Most of the time, I’m working on site with customers. But when I have a day where I’m going to the office, it feels like coming home. You immediately feel the positive vibe. People enjoy what they are doing. It’s difficult to describe this feeling… you need to experience it to understand it.

Another thing is that everybody is trying to help each other. When I started at CTG, there was a thing they called a SIG (Special Interest Group). These SIGs were groups of people getting together occasionally to share knowledge on topics they were passionate about. Fast-forward 17 years and these SIGs have evolved in Centres of Excellence (CoE). But at the core, it’s basically the same thing. Beside these centers we also encourage knowledge sharing by organizing Masterclasses en learning on the job by hosting regular Lunch & Learns where people get together during lunch to discuss specific topics of interest or have a small workshop. These L&L sessions are short, to the point and they work. They enhance the interaction in the different teams and encourages people to share their knowledge. The internal communities are like small ecosystems that live independent from each other but regularly bond and interact to join forces when needed. Not only on a professional level but also after work, these small communities get together to have some fun.

On a personal note, CTG meant a lot to me during one of the most difficult periods of my life. In 2015, after 9 years of trying, we were finally expecting our first child. But we lost our little boy during labour. After the initial shock, I notified my manager and unit manager that I was taking all of my vacation and that I needed time to process this. They immediately acted and relieved me from all administrative burdens. Family comes first. My customers were notified, and colleagues took over some my most urgent assignments without any hesitation. The sheer number of messages I received the first day from colleagues, office staff and management was so overwhelming, it took me 2 days and a lot of courage and tears to get through them. It took me 2 months to find enough courage and energy to go back to work. I was a bit worried I would see a lot of people trying to comfort me and I was not looking forward to those awkward moments. I didn’t feel like talking about it very much at that time. But to my surprise, none of my customers confronted me with this… which meant that CTG handled my absence with the upmost discretion. And I respect that. Says a lot about a company and how much they care about the wellbeing of their employees. They understand it’s the people that make your company, not just numbers and figures.

I currently have the role of Service & Technical Owner (STO) of the Business Productivity Solutions team. This team focuses on Office 365 and SharePoint and assists our customers in setting up modern workplaces or assist customers in transforming their traditional collaboration environments in modern collaboration workplaces. This is a very challenging role because Office 365 is a constantly changing platform where services come and go. Being an STO involves me on a higher level in decisions which are made to grow the company. Our management believes firmly in the importance of having senior consultants in these roles as they have a solid knowledge of their area of expertise and can be a bridge between the management and the people who are doing their best every day to build and expand the services we offer to our customers. This emphasizes the efforts the management do to involve the people in decisions which might affect their professional lives.

No bad memories, no times where the dark side tried to lure me away? Sure, there have been times. I’m not going to lie about it. Everybody has those moments of frustration and irritation. But then I think back to those past 17 years, what are the chances I’m going to find another great company like that? Lots of colleagues left, but a lot of them also came back because they missed CTG and its unique culture. That says it all.

If you want to be part of this family, don’t hesitate to drop a line. Our doors are always open, and we are always on the lookout for people who fit in the organization and are talented in what they do.

The Importance of Completing Tasks in Workflows

When you use workflows in your organization to automate business processes, you have to deal with the fact that people are lazy. They don’t like work. One of the things you do a lot in workflows, is create tasks. Somewhere in a process, somebody needs to complete a task before the next step in the process can be completed. So, the task is created and your workflow waits until someone completes it. The importance of completing tasks in the context of workflows is often underestimated. Completing a task in the context of a workflow is a 2-step process and this is a concept which lots of people don’t seem to understand and this leads to a lot of problems.

  • Step 1: Executing the action in the task
  • Step 2: Mark the task completed

Let me give you an example on how this might lead to issues.

You have an onboarding workflow for new employees. This workflow initiates several other workflows.
One of those other workflows is the creation of an Exchange mailbox. This “Exchange Mailbox Creation” workflow creates a task for the Exchange admins which instructs them to create a mailbox for the new employee.

Meanwhile, the main workflow handles some other stuff which is important for onboarding the new employee. Somewhere at the end of the process, the main workflow is going to check if the mailbox has been created. As long as the mailbox is not created, the onboarding process cannot be completed.
To do this, the workflow contains a loop which checks if the Exchange Mailbox Creation workflow is completed. If it’s not, It’s going to pause for 1 hour and check again. This repeats itself until the Exchange Mailbox Creation workflow is completed.

The problem is… that workflow will NEVER end because the people who are responsible for creating Exchange mailboxes do understand the importance of creating a mailbox for a new employee, but don’t understand the importance of marking the task completed in the system. They don’t know that the overall onboarding process relies on the completion of those tasks.

Direct results :

  • The Exchange Mailbox creation workflow will be waiting indefinetely unless someone sets that task to completed
  • The onboarding process for this employee will never finish because of the Exchange Mailbox Creation workflow will never finish

Indirect results:

  • The history list will grow constantly because of the loop which generated 2 list items every hour (for the pause action). Read this post to understand the importance of maintaining a history list.
  • The workflowprogress data table will grow constantly because of the same loop. Read this post to understand the importance of workflowprogress data.

A workflow designer has the responsibility of covering this by :

  • including reminder notifications in the tasks
  • Have some kind of escalation procedure in the case nobody bothers to complete those tasks. Escalating to a manager often helps
  • Make sure that the task notifications stress the importance of completing the tasks for a proper process termination. This should also be emphasized in the reminder notifications or escalations as well

For the example of the onboarding process, I had 91 running instances which have been running for months up until a year because of these incompleted tasks. These 91 instances are responsible for a history list that grows with almost 4400 list items every single day.

You can avoid all of this by thinking through your process and include logic in your workflow and tasks to avoid these situations. But if you are tasked with cleaning up an environment where these kind of issues exist for a while, you might have an environment which has thousands of running workflows that keep filling your history lists and workflowprogress tables with useless information and you need a way to stop this madness.

If you are using Nintex Workflow, you can use the below which allows you to terminate Nintex Workflows in batch. You specify your Nintex content database and a date and the script will terminate all running instances that didn’t have any activity since the specified date.

Keep in mind that terminating workflows might result in notification emails being sent by the system.


Maintaining Nintex Workflow Progress Data

In my last post I talked about maintaining the workflow history lists throughout SharePoint. This post is about maintaining Nintex workflow progress data. This data is found in the WorkflowProgress table in a Nintex content database.

When a Nintex Workflow is executed, each action is recorded in the WorkflowProgress table. This gives the system the opportunity to show a graphical representation of the workflow history for a specific instance. You can imagine that this table can contain a lot of information. Nintex recommends to keep this table below 15 million rows to avoid performance issues.

To maintain this table, you can use the PurgeWorkflowData operation of nwadmin.

The PurgeWorkflowData operation has a lot of parameters to specify which records it needs to purge. These parameters might not be enough to limit the records you want to purge. There’s a little catch in purging workflow progress data. To allow proper maintenance of the workflow history data, you need to make sure that you only purge workflow progress data for workflow instances where NO workflow history exists anymore. This means that there’s an order in how to maintain both the history lists and the workflowprogress table:

  1. Workflow History Lists
  2. WorkflowProgress table

If you purge the WorkflowProgress table before you clean the workflow history, you will end up with history list items which cannot be purged anymore in a selective way (using the ‘PurgeHistoryListData’ operation of nwadmin). You can only purge them by clearing the list completely.

Read more

Cleaning Workflow History in SharePoint

A lot of organizations that use SharePoint, use the platform to automate business processes using workflows. But little organizations are aware that because of these workflows, your SharePoint environment needs to be maintained a little more than usual. Almost all organizations which use a lot of workflows start having performance issues. SharePoint is starting to get slow, workflows are starting to show weird startup behaviors or don’t start at all. Those kind of things. And they don’t know why this is happening. One of the causes for this are probably the workflow history lists.

Which lists? Workflow history? We don’t have such lists.
Yes you do, but you don’t know it, because they are hidden! The comments and events you see when you look at a started workflow… these are stored in the workflow history list. Because those lists are hidden, most of the organizations who never had to deal with these issues, don’t know these lists exist and so, those lists grow and grow and grow. Up to a point it starts to get problematic.

To give an example, I had a case where the largest workflow history list contained 24 million items. For the entire environment, the combined size of all workflow history was 39 million items. That’s a lot of history. And honestly… nobody cares about this information. It’s only used in the event something goes wrong in a workflow and you need to find out why. But in highly regulated or audited environments, this history data can be important.

If you use Nintex Workflow, you can purge those lists using a single command. But if you try to do this on a list that contains millions of items, chances are that you will run into issues. The list has become too big. And again… purging the data is not always possible due to policies.

Now what? You will probably start searching for a solution… in the end, it’s just a SharePoint list like any other list, right? Online, you find some hints on how to approach those lists:

  • Easiest option… create a new list, change the workflows to use that new list and just delete the old one. That’s the quickest way to deal with this. But then you will lose all history. Each history list item has an event type from 1 to 11. Suppose you want to retain the events which hold a record of task outcomes. Deleting the list isn’t an option anymore and you need to find a way to selectively delete list items.
  • Create a script that deletes the items. Well, seems logical to do this. But you need to find the most optimal way of deleting items. Ever deleted SharePoint items in large lists? If you have, you know that SharePoint takes it time to do this. In a specific case I had a delete frequency of 1 item per 9 seconds, for a list of 32000 items. You do the math… that’s 80 hours. Which is a lot. Imagine you have to do this on a list of 24 million items. Best case… it takes 9 seconds per item. That’s 2500 days! Or almost 7 years! Completely insane.

So, out of options?

Well no. If you need to retain specific items on that list, deleting individual list items is still an option. But you need to use a different approach.

Instead of iterating over the complete collection of items in a list and delete one by one, you can use a batch processing method which exists on the SPWeb object. This batch processing method accepts an XML structure that contains “methods”. Each method is an instruction to delete an item in a list.

Each method contains the GUID of the list you are targeting, the ID of the item, and a command. In our case “Delete”.

Once you have assembled this structure, you pass it as a parameter to the ProcessBatchData method on the SPWeb object and SharePoint will perform all of the methods in batch.

To give you an idea on the performance of deleting items using this method. It deleted 215000 items in 16 hours. Compare this to 32000 items in 80 hours. That’s a huge improvement.

How would you practically do this?

Well, you use a CAML query to get a bunch of items from your history list and you assemble your batch xml for these items. Once it has been processed, you repeat the query and do it again… until you run out of items.

Here’s an example. The script below is going to remove all list items which have an event type of 0, 4, 5 or 11. The query returns 2000 items at a time and assembles the required batch xml for these 2000 items. The “ListItemCollectionPosition” is used to know when we are at the end of the list and out of items to delete. When this is null after you execute a query, there are no more items to query.

Running this on a list with 24 million items still requires a lot of time. And you might question the importance of retaining events for such lists… but in any case, you now have a faster way of deleting items in a SharePoint list.

In the end, you need to avoid getting in such a situation in the first place. You can do this by establishing some governance policies regarding workflows and create some routines to enforce those policies by performing maintenance on a continuous basis. That way, you will be able to keep those history lists under control.

Gaining insights in your Nintex Workflow Data

Working with workflows in SharePoint is always a challenging task. Especially when you are an administrator and people start complaining about performance issues, workflows that don’t start or resume, and so on. Using Nintex Workflow doesn’t change anything, but it gives you a bit more leverage.

The first thing I always do, is try to get some insights in the size of the issue. So, we’re talking about data. How much workflow data is involved. When Nintex is involved, there are 2 places where I’m going to look:

  • Workflow History Lists (SharePoint)
  • WorkflowProgress table (SQL Database)

Nintex has an article on both topics which I can definately recommend.

This article links to a PDF which explains how to maintain the WorkflowProgress table. You can find that PDF here.

In this PDF, you will find a SQL query which queries this table and the WorkflowInstance table to give you an insight in the sheer amount of data which is stored and which might be the root cause of your issues with workflows.

Just for you lazy people, here’s the query:

This gives you a lot of information which you can use in your remediation strategy.
Just export that information to a CSV and load it in Excel and you can have the following information at hand in no time.

workflow data

This is a table which gives you, per Nintex content database, the amount of records in the workflowProgress table (ActionCount) and the number of workflow instances involved. And it splits up this information for the different states workflows can be in (running, completed, canceled, error). Whoever came up with the concept of Pivot tables… thank you! 🙂

While this query is great for getting that information and report on it, it’s not that useful for people who are responsible for creating or maintaining those workflows. Look at the query. It gives you the site, web, list and even item that’s involved. But those are the ID’s. You still need to resolve these to a URL or title of a list to be useful for anyone who’s not an administrator on SharePoint and knows his way around in PowerShell.

You could customize this query and include the SharePoint content databases in there to get you the needed information but you know you shouldn’t touch those databases in SQL! So, that’s not an option.

I decided to make my life a little less complicated and use PowerShell to solve it.
The script below is going to execute the query above (with some minor adjustments to get some extra information) and after getting the results, it will get the corresponding URL’s for site and web, and the title of the list (if needed). All of this information is exported to a CSV.

This not only gives me information I can work with immediately, but it also allows me to do it all from my SharePoint server. I don’t need a SQL Management studio anymore or physical access to the database server.

Depending on the amount of rows that is returned from SQL, the execution of the script can take some time though. I tried to minimize the calls to SharePoint by using arrays where I store the URL’s and titles for found GUID’s. This reduces the stress on SharePoint a bit but it still requires some time to go through each row.

Using this list, you can prioritize the things to focus on during a cleanup. And it gives you also the ability to predict the impact of a purge on that table using specific parameters.

Welkom kleine Bram

Welkom kleine Bram

Eindelijk is het zo ver. Hier hebben we zeer lang naar uitgekeken. op 24/04 werd onze Kobe* grote broer van Bram. Een stevig kereltje van 4,025kg en 53cm.


Het zijn een helse 9 maanden geweest. Mensen zeggen altijd dat je moet genieten van een zwangerschap. Misschien voor velen wel. Maar voor mij was het allesbehalve genieten. Je kan je nu afvragen hoe een vader nu niet kan genieten van een zwangerschap. De moeder, ok. Die heeft alle lasten erbij. Maar begrijp mij niet verkeerd… uiteraard waren er veel momenten dat WE konden genieten. Jawel, we. Vooral wanneer de schopjes voelbaar zijn, dan is het genieten. Maar tegelijkertijd ben je ook op geen enkel moment nog gerust. Zeker niet als je even niets meer voelt. Of de periode tussen de moment dat Sindy niet meer misselijk was en de moment dat de bewegingen voelbaar zijn. Dat zijn stresserende momenten omdat je in een blinde periode zit waar je buiten het buikje dat langzaam groeit eigenlijk geen gevoel hebt dat je zwanger bent. En van zodra het einde van de zwangerschap nadert, begin je je opnieuw meer en meer zorgen te maken. Je leest en hoort in de krant wat berichten zoals het bericht van Sergio Herman en zijn vrouw die hun kindje hebben verloren op het einde van de zwangerschap. Dat zijn dingen die je echt niet wil lezen op zo momenten. Zeker niet als je zelf in die schoenen hebt gestaan. Dan is elk signaal een paniekmoment.

Maar uiteindelijk kan je echt niets doen om het meer draaglijk te maken. En dat is frustrerend. Naar het einde toe heb je zowiezo meer controles en je kan op elk moment van de dag en zoveel als je wil, langsgaan op de materniteit om even aan de monitor te liggen als je even ongerust bent of je zorgen maakt. Men moedigt dit zelfs aan. Maar dit neemt de zorgen maar even weg want wij weten dat het een kwestie van uren kan zijn. Je kan een perfecte monitor hebben, naar je wagen stappen op de parking en het kan daar al mislopen. Ze geven eigenlijk een vals gevoel van zekerheid. Maar het is wel goed dat deze er zijn, zodat je af en toe toch nog die bevestiging krijgt dat het nog OK is. Ook al weet je dat dit niets wil zeggen. Het liefst van al zou je willen dat je vrouw 24/7 aan de monitor ligt. Maar dit is uiteraard praktisch niet realistisch…

Bram was uitgerekend voor 29/04. Maar op 14/04 werd ik iets na middernacht wakker gemaakt door Sindy die naast het bed stond te trillen op haar benen. Mijn eerste reactie was: “Is er nog beweging?”. Want ik vreesde een zelfde scenario als bij Kobe*. Gelukkig kreeg ik bevestigend antwoord. Meer dan genoeg beweging. OK… next step. Wat gaan we doen? Nog afwachten of eens bellen met materniteit? Afwachten was geen optie, dat was klaar en duidelijk. Ondanks het feit dat er beweging was, was er toch nog altijd een ongerustheid. Dus gebeld naar materniteit. Zij kenden de voorgeschiedenis en namen ook geen risico… kom maar naar materniteit. Daar hebben we aan de monitor gelegen en bleken het oefenweeen te zijn maar was er ook reeds 4cm opening. Verder was er volop beweging in de buik, en een gezond hartslagje op de monitor. Weer een beetje gerustgesteld. Maar de vroedvrouw twijfelde om ons gewoon terug naar huis te sturen en na consultatie met de gynaecoloog van wacht hebben ze beslist dat we mochten blijven en werden we verhuisd naar het verloskwartier. Daar hebben we dan gelegen en gewacht… uiteindelijk bleef het bij 4cm. 16u later was er nog steeds geen vooruitgang. Dan hebben we beslist om het af te breken. Sindy is wel nog een nacht gebleven ter observatie. Dit was het begin van de meest stresserende 2 weken uit mijn leven.

Gedurende die 2 weken hebben we ettelijke keren aan de monitor gelegen. Vrijdag 21/04 moesten we op controle bij de gynaecoloog en die stelde voor om niet langer te wachten en het lot niet langer te tarten. Hij zou maandag 24/04 de vliezen gecontroleerd breken.
Toen we ‘s maandagsmorgen ons aan het installeren waren op de kamer heeft onze meneer echter eigenhandig de vliezen gebroken en zijn we verhuisd naar de verloskamer. Daar hebben we nog tot 14h15 moeten wachten op de bevalling zelf. Omdat onze grote vriend geen seconde stil lag hebben ze beslist om de uitwendige monitor te vervangen door een STAN-monitor, waarbij een electrode rechtstreeks op het hoofdje wordt geplaatst om zo een accurate meting te hebben en ook een indicatie te hebben wanneer de baby in nood zou verkeren nog voor dit effectief het geval zou zijn. Een hele geruststelling.
Maar je ziet dan op die monitor bij elke contractie de hartslag van de baby naar beneden duiken… perfect normaal zegt men ons. Hij mag enkel niet te dikwijls te diep zakken omdat hij dan van te ver moet terugkomen na elke wee. Als je dan bij elke wee even hoort dat de STAN geen hartslag registreert gedurende een seconde of 5, dan voel je die paniek weer naar boven komen. We bekijken elkaar… keizersnede… NU! De vroedvrouw knikt begrijpelijk en belt de gynaecoloog. Die vindt het echter nog te vroeg om nu te beslissen. Komaan vriend! Ik sterf hier van de stress!

Om 14h is de gynaecoloog dan gearriveerd en is men eraan begonnen. Om 14u15 was het achter de rug. Maar hij heeft zich niet zomaar gewonnen gegeven. Zijn hoofdje lag in de verkeerde richting. Hierdoor was een keizersnede nog steeds niet uitgesloten. Maar men wilde eerst proberen via een gewone bevalling door gebruik te maken van een kiwi-cup en dan tijdens het persen het hoofdje te draaien. Tegelijkertijd werd de kinderarts verwittigd om af te komen. Blijkbaar routine wanneer ze zo’n cup gebruiken. Men is er in geslaagd om het te draaien en het team in de operatiezaal dat klaarstond voor een keizersnede uit te voeren, mocht beschikken. Er was echter wel een groot probleem. Het hoofdje was wel gedraaid, maar de romp niet volledig. Hierdoor zat een schoudertje klem. Als je ooit een gynaecoloog wil zien paniekeren, dit was zo’n moment. Nu was het een kwestie van minuten… het moest nu gebeuren want de baby verkeerde in nood. Een extra knipje, even met 2 extra duwen op de buik, met 2 trekken aan die cup… geen prettig moment! De dokter was net binnen toen men Bram gehaald had en die heeft hem direct meegenomen naar de recovery ernaast om hem de eerste zorgen te geven. Geen geween, geen gekreun… Het heeft slechts een minuutje geduurd, maar het leken uren… dan ineens een gil, een ween. Hij heeft het gehaald! Alle emoties de vrije loop!
We hebben hem dan een minuutje gezien en vastgehad. Daarna heeft hij 3 dagen op neonatologie gelegen om terug op krachten te komen want hij had het echt moeilijk die eerste uren.

Maar alles is goed gekomen. Onze jongen had ongetwijfeld een beschermengel die over hem heeft gewaakt.

Nu kunnen we beginnen aan het volgend hoofdstuk in ons leven. Kobe* zal altijd onze eerstgeboren zoon blijven maar hij is in goede handen waardoor we onze aandacht nu kunnen geven aan Bram die naast zijn ouders ook zijn grote broer heeft die over hem zal waken.

We zijn ondertussen 2 weken verder. Bram is een guitig baasje met een enorme eetlust 🙂 Heeft hij waarschijnlijk van de papa. 

Bram-02 Bram-03

Ik probeer mijn enthousiasme wat beperkt te houden omdat ik weet dat er mensen mijn posts over Kobe* hebben gelezen en hebben gereageerd dat ze ook met dergelijke zaken worstelen en zij niet zoals ons het geluk hebben om alsnog zo’n wondertje te mogen verwelkomen. Voor hen kan ik enkel maar hopen dat er ook goed nieuws volgt. De hoop niet opgeven klinkt cliché, maar het is jammer genoeg het enige wat je kan doen.

Toch ook even een dikke pluim voor de mensen van de materniteit en neonatologie van RZ Tienen. Zij hebben ons die laatste 2 weken voor de bevalling en de week na de bevalling enorm goed begeleidt. Ze wisten waar we van kwamen en gingen heel begripvol en geduldig te werk. Ze luisterden naar onze verhalen, onze bezorgdheden en probeerden dit ook zo over te brengen aan de dokters. In het bijzonder vroedvrouw Petra en stagiaire Caroline die erbij waren tijdens de bevalling, en de uren voor en na de bevalling. Zij stonden op elk moment klaar voor ons. Ik ga ervanuit dat ze dit uiteraard voor alle toekomstige mama’s en papa’s doen. Ook Gerbe van neonatologie… zo fijn en lief dat zij omging met de kleine ukkepukjes. Ik heb een grote bewondering voor hen. Zij hebben ons het gevoel gegeven dat we niet gewoon patient x waren, maar dat we echt meetelden.

Following sites not working in a Hybrid Sites scenario – 401 Unauthorized

Earlier this week, I was at one of my customers which has a SharePoint 2013 implementation. They had an issue where following sites was not working anymore. When they clicked the Follow link, they got an error that the site could not be followed.

They have a hybrid implementation with OneDrive for Business and Hybrid Sites setup.
When I looked in the ULS, I saw the following error popping up

Loud and clear… authentication issues.

Microsoft has an excellent resource where they outline the roadmap to implement hybrid features.

Both roadmaps outline the steps which are needed to set up those features. Since OneDrive for Business was working fine, I focused on the Hybrid Sites features and started going through the steps of the roadmap to see if everything was set up correctly.

  1. Configure Office 365 for SharePoint hybrid – Check!
  2. Set up SharePoint services for hybrid environments – Check!
  3. Install the September PU for SharePoint Server 2013 – We were on the December 2016 CU, so … Check!
  4. Configure S2S authentication from SharePoint Server 2013 to SharePoint Online –  Hmmm… I don’t recall doing this in the past.
  5. Configure hybrid sites features in Central Administration – Check!

Since I was getting authentication issues, and I didn’t recall me doing the S2S authentication configuration step, I figured that this was the cause of the problem.

When you follow the link for that step, you will see that there’s some work to do to set it up. Luckily, Microsoft provided a tool which actually does it for you. It’s called the Hybrid Picker. This simplifies things a bit.

Read more

Stressed out

We zijn ondertussen 6 maanden ver in de zwangerschap van een broertje of zusje voor Kobe. De kerstboom heeft dit weekend plaats gemaakt voor het park dat terug klaar staat. De babykamer die volstond met spulletjes begint ook terug wat in orde te komen. Gisteren heeft Sindy een suikertest gedaan en de resultaten waren aanvaardbaar. Ze moet net geen uitgebreide test laten doen. De dokter heeft ook nog eens even met de doppler een check gedaan en alles zit goed. Maar dat wisten we al. Als er 1 ding zeker is, dan is het dat het geen zittend gat heeft. Gelijk de papa! 🙂 Er wordt duchtig gestampt en rondgedraaid in de buik. Dat maakt het voor mij des te leuker omdat ik er zo ook een beetje van kan genieten. Alhoewel “genieten” een relatief begrip is…

Ben gisterenavond ook bij de dokter gepasseerd. Mijn driemaandelijkse check-up voor mijn bloeddruk. Ik neem al enkele jaren medicatie voor een te hoge bloeddruk. Hij was niet dramatisch hoog. Tussen 90 en 100 voor een onderdruk en tussen 140 en 150 voor de bovendruk. Maar dit is toch te hoog om niets aan te doen. Ik had ook al jaren last van hoofdpijn en ondanks het feit dat de dokter zei dat dit niet van de bloeddruk kon zijn, was dit de enige reden dat ik kon bedenken waarom ik ze altijd had. En inderdaad… nadat ik ben begonnen met mijn medicatie, is die hoofdpijn dan ook bijna compleet verdwenen… tot een maand of zo geleden.
Ik begon te merken dat mijn hoofdpijn frequenter terugkwam. Niet in de mate van vroeger, maar zo een sluimerende hoofdpijn… te weinig om iets in te nemen, maar toch aanwezig. Ik heb thuis een bloeddrukmeter liggen voor zelf wat op te volgen en ook daar zag ik dat ik opnieuw waardes begon op te meten die te hoog waren. In het begin was dit sporadisch… maar de laatste weken zit ik constant weer boven de 90 en 140. Net alsof mijn medicatie niet meer werkt. Er zijn geen fysieke of medische redenen die dit kunnen verklaren omdat ik niet ziek ben of zo. Ook is die medicatie niet onderhevig aan gewenning.

Dus is er een andere reden. Als ik terugkijk naar mijn metingen, dan kan ik zien dat ik sinds begin november terug hoge waardes ben beginnen opmeten. Ik had na Kobe al gezegd dat als we opnieuw zouden beginnen en we zouden opnieuw zover geraken, dan zou dit voor mij van begin tot einde een periode zijn dat ik mij zorgen maak. En dit is ook zo. In het begin maakte ik mij nog niet al teveel zorgen… we zien wel. Waarschijnlijk omdat ik het zelf eerst niet wou geloven dat we dat nog mochten ervaren. Maar na die eerste echo is dat begonnen… en elke week die er bij komt, neemt de stress bij mij toe. Ik voel het zelf heel goed. We zitten op 6 maanden… als het vanaf nu misgaat, dan ben ik papa van een 2de sterretje. En ik weet niet hoe ik dat zou moeten verwerken. Ik wil daar niet aan denken, maar doe het toch. En dat spookt door mijn hoofd. Ik ben zodanig sceptisch geworden, dat ik pas zal geloven dat alles goed is, wanneer ons prutske in mijn armen ligt te janken of te slapen. Pas dan zal ik terug rust vinden… en dan zijn er weer andere zorgen.
Mijn broer en zijn vrouw waren ook zwanger en waren uitgerekend voor eind januari. Door complicaties hebben ze de baby halverwege december al moeten halen en heeft hij tot 2 weken geleden op de Neonatale Intensieve Zorgen in Brugge gelegen. Gelukkig is het een gezond bazeke en loopt alles goed met zowel hemzelf als de mama. Tegelijkertijd was de dochter van de buren bij mijn ouders ook zwanger en ook daar hebben ze door complicaties de baby moeten halen op 31 weken… daar was het zelfs levensbedreigend voor moeder en kind. Ook daar alles gelukkig goed gelopen. En dan is er ook nog een kennis van Sindy waar het dochtertje te vroeg is geboren maar het niet gehaald heeft. Deze dingen helpen niet voor mijn gemoedsrust, hé. En dus maak ik mij zorgen… elk uur van de dag. Het is niet dat ik niet meer functioneer of geen energie meer heb of dat mijn werk en dergelijke er onder lijdt, maar het is iets wat constant aanwezig is als een peuter die aan uw broek zit te snokken omdat ie aandacht wil.
Zit ik ’s avonds in de zetel, dan zit ik niet rustig tot ik zélf heb gevoeld dat het nog OK is. En dan nog… als Sindy even zucht of kreunt omdat er iemand op een blaas zit te duwen, dan flitst er vanalles door mijn hoofd. Moet ze ’s nachts opstaan om naar het toilet te gaan en ik word wakker, dan flitst er opnieuw vanalles door mijn hoofd. En dit gaat maar door en door. Het ene scenario na het andere doorloop ik in mijn hoofd. Ik word daar knettergek van!!!! En uiteindelijk is dat niet goed voor mijzelf, maar ook niet voor Sindy. Zij heeft daar onrechtstreeks ook last van.

stressed out

En er zijn nog een 3-tal maanden te gaan. Dat beloofd. Ik heb één chance en dat is dat ik er mijn slaap niet voor laat. Dus mijn nachtrust heb ik nog wel.

Dus ja, zowel ikzelf als de dokter, aan wie ik gisteren hetzelfde heb gezegd, zijn ervan overtuigd dat mijn medicatie niet opgewassen is tegen de stress die ik momenteel ondervindt en dit zal erger worden naarmate we dichter bij het punt komen dat het is misgelopen met Kobe. Tijdelijk krijg ik dan ook zwaardere medicatie en is het dagelijks opvolgen en als het niet beter wordt, bijsturen. Ze is er wel van overtuigd dat het na de bevalling terug zal normaliseren. Ik hoop het… Ik ben iemand die niet snel gestresseerd is en vrij rustig is, maar dit heb ik echter nog nooit meegemaakt. Ik ben zelfs rustiger op het werk dan thuis voor de moment. Ik voel mij net een elastiekske dat aan het uitrekken is en waar je van wéét dat de rek er vroeg of laat gaat uit zijn. Ik tel de dagen bijna letterlijk af op een kalender… hopende dat het elastiekske het houdt.

Ik zal in ieder geval zo blij zijn als dit achter de rug is en ik opnieuw rust heb gevonden. Rust die dan waarschijnlijk door iemand anders zal worden verstoord… meerdere keren per nacht… maar daar teken ik direct voor. 🙂

Convert a SharePoint 2016 front-end to a front-end with Distributed Cache

I have been running a SharePoint 2016 farm with 4 servers (Front-End, Application, Distributed Cache, Search) but now Feature Pack 1 has been released, I’m looking to reduce this to 2 servers and use the 2 combined minroles which have been added. To be more precise, I want to eliminate my Distributed Cache server and convert my Front-End to a Front-End with Distributed Cache. After that, I want to do the same for my Search server and convert my application server to an application server with search. But doing this for my Distributed Cache server, proved to be a challenge. I was getting all kind of errors. This might have something to do with the order I did things though.
Before I did the conversion, I removed my Distributed Cache server from the farm and I didn’t do this in a graceful way… I just disconnected it from the farm.

My first attempt to convert a server failed with a very self-explanatory error:

The Distributed Cache service instance must be configured. Run ‘Add-SPDistributedCacheServiceInstance -Role WebFrontEndWithDistributedCache’ on this server to configure the Distributed Cache service instance.


That’s pretty clear. This is indeed a front-end server and in SharePoint 2016, this role doesn’t have the Distributed Cache service instance. So, I added it like the error proposed.

The result however was not what I expected. I got the error:

Failed to connect to hosts in the cluster


Come to think of it… this actually makes sense. I already mentioned I kicked out the Distributed Cache server in a very direct way. Probably, my cluster is still referencing this host. The only way to verify this is to look at the cluster configuration. To get this information, you can export it to a text file.

Somewhere near the end of the file a “hosts” section can be found and this contained the following information:


And this confirmed it. The old host was still listed in the configuration. I had to remove this host first. To do this, I executed the following command:

This succesfully unregistered my host from the cluster and I re-ran the command to add the Distributed Cache Service Instance.

This time, no error! Hooray!

I proceeded to run the Set-SPServer command again to start the conversion. Again, an error appeared. This time, the error was different.

The Distributed Cache service instance must be reconfigured. Run ‘Remove-SPDistributedCacheServiceInstance’ on this server to remove the Distributed Cache service instance. Then run ‘Add-SPDistributedCacheServiceInstance -Role WebFrontEndWithDistributedCache’ on this server to reconfigure the Distributed Cache service instance….


At this point, when you look at the Distributed Cache service in Central Administration, you can see that it’s stopped. If you open the Windows Services console on the server, the AppFabric Caching Service is disabled.

I tried to remove this service using Remove-SPDistributedCacheServiceInstance, but it failed with the error:

cacheHostInfo is null


To get past this point and get the service removed, you can execute the following piece of PowerShell script:

This worked and it removed the service instance completely from my server.

I then proceeded to execute the Add-SPDistributedCacheServiceInstance command again but this time without the -Role parameter!!!

When the command finished, I went to the Services on Server page in Central Administration and I noticed that the Distributed Cache service was added again. This time it was started! It also stated that my server was not compliant anymore but who cares…. we are going to change the role anyway.


I re-ran the Set-SPServer command to start the conversion:

And yes, now it worked. I was notified that a timer job had been scheduled to do the conversion.


I only had to wait until the job was completed. When I looked at the Servers page in Central Administration, I could clearly see that my role was changed and that the server was compliant.


Part of this could possibly have been avoided by removing the Distributed Cache server in a more graceful way. Lessons learned… don’t cut corners!  😎