Tool: ServiceWatcher

It was Sunday 09:45, the birds were cheerping and the sky was blue, when suddenly this peace was interrupted by the ring of my phone. That’s right, I was on stand-by duty that week and my consumer just called to inform me that the production environment of Citrix is down.

After some question I determined there, indeed, is something wrong so I started my laptop, logged on to the environment and started troubleshooting. Hmmm, no icons on Storefront? That must be the database.

Once headed to the database server, which is on Server Core, I fired the command Get-Service -Name MSSQLSERVER which showed me the service was not running. That’s weird, because the start-up type of the service was on Automatic. I started the service and the issue seemed to be solved. I realized the servers were automatically patched on Sunday, could this be related to a reboot?

I decided to perform a system info to determine the boot time of the server, and this confirmed the server has suffered from a reboot.

So, to prevent this from happening again I need something to make sure SQL is getting started when it’s down, so I can enjoy my well-deserved sleep 😁
I went ahead and started programming some PowerShell after which I converted my script to an executable. The script works with the input of a JSON file, which is easy to read. This JSON file needs to be installed in “$env:ProgramFiles\TimTools\ServiceWatcher\ServiceWatcher.json” / “%programfiles%\TimTools\ServiceWatcher\ServiceWatcher.json. You are free to choose where you will place the executable file, but the most logical place to me is to store it in the same folder:

Once satisfied with the location you can than install the service with the following command:

.\ServiceWatcher.exe -install
Start-Service ServiceWatcher

Of course, you can also uninstall the service with ease:
.\ServiceWatcher.exe -uninstall

Or when you lost the executable:
sc.exe delete ServiceWatcher

Let’s put it to the test, in the example below we’re testing with Citrix components, but of course you can specify each service you like and you can even use wildcards like in the example below:

The application has only been tested on Windows 10 21H1 and Windows Server 2019 but should theoretically also work on Windows 7, Windows 8/8.1, Server 2008, Server 2012 and Server 2016. However, I do not recommend the use of deprecated operating systems. More information about Windows lifecycles can be found on https://docs.microsoft.com/en-us/lifecycle/products/

So, after implementation I think it’s fair to say I nailed it and now I can go back to sleep.

If you’ve encountered a bug/question/feature request, feel free to contact me on LinkedIn.

The application can be found on GitHub.

Author: Tim Nissen

5 tips voor de adoptie van DevOps in een werkplek strategie

Leestijd : 3 minuten

Veel organisaties zijn actief bezig met de transitie naar een DevOps strategie. Hoewel DevOps een veel gebruikte methode is binnen de softwareontwikkeling is het wellicht een nieuwe aanpak voor andere afdelingen zoals bijvoorbeeld de wekplek beheer binnen een organisatie. Zo lopen veel organisaties tegen verschillende uitdagingen bij de adoptie van de DevOps strategie binnen deze afdelingen. In deze blog post voorzien we je van 5 tips voor een betere adoptie van een DevOps strategie.


Voor diegene die nog niet bekend zijn met DevOps, DevOps is een set van middelen voor het combineren van software development (Dev) en IT-operations (Ops). Het is bedoeld voor het inkorten van de development lifecycle en intoduceert ook nieuwe manieren van werken zoals bijvoorbeeld continous delivery. Meer informatie over DevOps is hier te vinden.

 

1. Think big but start small

Desondanks de werkplek relatief simpel in gebruik is, komen er veel verschillende componenten bij kijken. In combinatie met het formaat van de organisatie moet je met verschillende zaken en afhankelijkheden rekening houden. Het is met die reden cruciaal om een hoog-over doel te hebben wat te bereiken met de DevOps strategie binnen de afdeling. Gezien de hoge mate van verandering van de verschillende componenten, is het daarom zeer belangrijk om de wendbaarheid (agility) zo veel mogelijk te verhogen.

Voor een werkplek strategie zal de focus liggen bij het automatiseren van de gehele infrastructuur. Hierdoor is het mogelijk om de gehele omgeving opnieuw op te bouwen zonder enige interactie van een medewerker. Dit zal het ultieme doel zijn waardoor de afdeling zich kan richten op het verhelpen van eventuele problemen en het iteratief toevoegen van nieuwe functionaliteiten.

Het is niet realistisch om het einddoel in een keer te realiseren. Helemaal binnen een werkplek omgeving zijn er verschillende componenten vereist voor de werking. Het is cruciaal om klein te beginnen om zo iteratief het einddoel te bereiken. Hierdoor zal het team kleine mijlpalen behalen en bekender worden met de verschillende (nieuwe) technieken binnen DevOps.


2. Alles in code

Voor sommigen zal dit misschien afschrikken maar ‘code’ is de core van een goede DevOps strategie. Met behulp van code is het mogelijk om alles te automatiseren binnen de werkplek omgeving. Alle DevOps oplossingen bevatten Git of een vergelijkbaar versiebeheersysteem. Door het gebruik van een versiebeheersysteem, zoals Git, zijn alle wijzigingen binnen de code inzichtelijk en traceerbaar. Voor het correct gebruik van Git is het advies om de juiste informatie op het internet te zoeken, zoals de volgende instructie video.

Learn Git In 15 Minutes – YouTube

Ervaring leert dat de learning curve best hoog is voor mensen die nooit gebruik hebbengemaakt van Git, en met die reden is de juiste begeleiding cruciaal.

Binnen veel DevOps oplossing wordt er ook gebruik gemaakt van Markdown. Markdown is een markup taal voor het formatteren van tekst. Het is vergelijkbaar met HTML, maar dan vele malen minder complex en is hierdoor gemakkelijk en snel op te pakken. Hierdoor is het mogelijk om ook direct documentatie op te nemen binnen de Git repository. Documentatie is door vele gezien als vervelend of niet noodzakelijk. Het is daarom belangrijk om allen relevante informatie op te nemen. Ervaring leert dat een detail level ontwerp vrijwel nooit meer gebruikt wordt en gezien de tijd en energie zonde is van de tijd. Met behulp van Markdown Architectural Decision Record, kan de structuur opgenomen worden voor het bijhouden van architecturale keuzes, wat het belangrijkste onderdeel is van documentatie.


3. Git strategie

Zoals in de vorige tip benoemd gaat het allemaal om de code. Code wordt opgeslagenin een versiebeheersysteem zoals Git. Git is dan ook de meest voorkomende oplossing binnen veel DevOps oplossingen. Desondanks dit nu specifiek om Git gaat, is dit van toepassing voor elke type versiebeheersysteem.

Binnen Git is het belangrijk om een goede strategie te benoemen betreft het gebruik van Git. Denk dan de structuur van je code repository maar ook hoe om te gaan met branches. Een branch is een aftakking dan wel een kopie van de code. Het is gebruikelijk binnen een werkplek omgeving om DTAP omgeving te hebben. Met behulp van branches is het mogelijk om een branch te hebben voor development, test, acceptatie en productie. Nieuwe functionaliteiten dan wel deployment zullen ontwikkelt worden in de development omgeving. Zodra de functionaliteit succesvol is deployed dan wel getest kan door middel van een merge of nog beter een pull request de code doorgezet worden naar test. Na het testen in de testomgeving gaat de code door naar acceptatie en als laatst naar productie.

De term pull request zal vaak binnen DevOps voorbijkomen, dit is een methode om wijzigingen binnen zowel de code als documentatie te reviewen. Helemaal in de tijd van remote werken is het een zeer prettige manier om de interactie aan te gaan over de inhoud. Met die reden is het advies om pull requests mee te nemen in de implementatie van de DevOps oplossing.

Er zijn verschillende uitgewerkte strategien beschikbaar op het internet en het advies is ook om goed in te lezen en een te adopteren binnen de omgeving. Een veel gebruikte strategie is GitFlow en is altijd een goed startpunt.

 

4. Pipelines

Mocht je in aanraking zijn gekomen met DevOps dan zal vast de term pipeline bekent voorkomen. Binnen alle DevOps oplossingen zit een pipeline of vergelijkbare mechanisme verwerkt om een stappenplan te doorlopen. In het stappenplan is het dus mogelijk om allerlei acties uit te voeren zoals het bouwen van een applicatie of in het geval van een werkplek omgeving, een machine uit te rollen en te configureren. De pipeline is dus de gehele motor om alle geautomatiseerd uit te rollen.

Bij het gebruik van een pipeline zijn een aantal principes belangrijk om rekening mee te houden. Maak de logica van de automation op een generieke manier zodat het bruikbaar is binnen de verschillende omgeving in de DTAP straat. Binnen de pipeline is het mogelijk om gebruik te maken van verschillende variabelen, onder andere de huidige branch. Met deze methode is het mogelijk om één pipeline te gebruiken voor alle deployments. Let hierbij wel op hoe de pipeline daadwerkelijk is opgeslagen binnen de omgeving. Binnen Azure DevOps zal een YAML gebaseerde pipeline in de Git repository worden opgeslagen. Hierdoor kan de branching strategie worden gebruikt om wijziging in de pipeline door te voeren. Indien de oplossing dit niet kan, is het verstandig om onderscheid te maken tussen de verschillende omgevingen.

 

5. Continous delivery

Binnen een traditioneel werkplek bouwtraject kan het soms maanden duren totdat een werkplek daadwerkelijk is opgeleverd. Dit is dan ookwel bekend als een waterval aanpak. Het bouwen gaat per component en zodra het staat is de taak van de beheerder om regulier beheer op uit te voeren. Onderdeel van de DevOps mindset is continuous delivery. Zoals eerder benoemt moet het op elk moment van de dag mogelijk zijn om de volledige omgeving op te bouwen zonder enige interactie van een persoon. Zo zou het in theorie mogelijk zijn om elke nacht de volledige omgeving opnieuw klaar te zetten zodat alles identiek en compliant is. Dit is geheel in lijn met een “immutable infrattrucutre” of “infrastrucure as code” strategie.  Wellicht gaat dat net iets te ver als startpunt, maar het is een goed steven als einddoel. Met de mindset om op elk moment te kunnen deployment creëer je de mogelijkheid om continue kleine onderdelen te releasen. Zo creëer je de wendbaarheid (agility) om snel te voldoen aan eventuele nieuwe wensen en eisen van de klant.

 

Conclusie

DevOps is niet alleen een toolset maar ook een mindset welke moet gaan leven binnen de organisatie voordat er daadwerkelijk waarde behaald kan worden met DevOps. Bovenstaande tips zijn een aantal aandachtspunten om rekening mee te houden bij het implementeren van DevOps binnen een werkplek omgeving. Geduld en begrip voor het leren van iets nieuws is daarbij zeer belangrijk, gezien de materie voor sommige nieuw en complex kan zijn.

Het is daarom belangrijk om ook goed te kijken naar de toolset binnen de organisatie. Het mag nooit zo zijn dat tools en andere middelen een beperking zijn bij het uitvoeren van je werk, helemaal als die het DevOps werk tegenhouden. Indien de toolset een beperking is, zal de adoptie alleen maar lastiger worden.

Afhankelijk van de werkmethodes binnen de organisatie kan het verstandig zijn om een Agile framework als SCRUM of Kanban te adopteren. Een belangrijk onderdeel van zo’n framework zijn de reviews. Dit is een ceremonie om aan verschillende stakeholder te laten zien wat de afgelopen iteratie is opgeleverd. Afhankelijk van het formaat van de organisatie is dit ook een mooi moment inzicht te krijgen wat andere afdelingen aan het doen zijn. Naast de review is de retrospective een belangrijk onderdeel om niet alleen het process, maar ook de mensen continue te verbeteren in hun werk.

Wil je meer weten over het gebruik van DevOps of eventueel hulp nodig? Vind hier meer informatie wat we vanuit RawWorks kunnen betekenen.

RAWWORKS EN CITRIX MICROAPP HACK-A-TON

In mei heeft RawWorks een interne en een openbare Citrix Microapp hack-a-ton georganiseerd met als doel om met een team van twee man de mooiste en slimste Micro-app te bouwen. De hack-a-tons waren goed bezocht en er zijn gave prijzen uitgedeeld. Het concept was als volgt; een korte training van 40 minuten en daarna zelf aan de slag met Microapps. De teams hadden twee uur de tijd om een proces naar eigen inzicht te automatiseren. Hierna volgde een korte presentatie voor de jury. Zie de Youtube video voor de resultaten.

Het is erg gaaf om te zien dat mensen die nog nooit iets hadden gedaan met Microapps na 40 minuten training in 2 uur tijd al iets werkends kunnen bouwen. Dit toont aan hoe goed het Low/No-code Microapps platform is van Citrix. Normaal zou het dagen duren om een eigen applicatie te schrijven die net zo goed op een desktop werkt als op een mobiel device zoals een smartphone.

RawWorks gaat meer hack-a-ton’s organiseren met een variatie van onderwerpen. Doe jij de volgende keer ook mee? Er zijn gave prijzen te winnen en er is sowieso altijd gratis pizza! Houdt onze LinkedIn en Twitter in de gaten.

Wil jij meer weten over Citrix Microapps en wat deze kunnen betekenen voor jouw bedrijf? Neem dan contact op met onze Technology Officer Chris Twiest (chris.twiest@rawworks.nl)

RawWorks behaalt VMware Master Services Competency Digital Workspace

Met trots kunnen wij vertellen dat wij vandaag de VMware Master Services Competency Digital Workspace hebben behaald!
In september waren wij een nieuwe partner op de VMware markt met een aantal solution competenties.
Deze hebben wij verder uitgebreid en uiteraard niet stil gezeten in de afgelopen maanden. 

Met nu het resultaat dat wij de Master Service Competency Digital Workspace hebben behaalt!
Wij mogen ons graag eren als een van de 10 VMware partners in Nederland met deze status.

Wat zijn Master Services competenties? 

Master Services Competencies (MSC’s) zijn VMware erkenningen die ontworpen zijn om expertise aan te tonen van partners welke door klanten zijn gevalideerd binnen een 
VMware oplossings gebied. 

Hoe bereikt een partner een Master Services Competentie?

Elke MSC vereist geavanceerde technische certificeringen, bewijs van expertise op hoog niveau gevalideerd door klanten waar opdrachten zijn uitgevoerd. Daarvoor nodig zijn:

Certificaten – een specifiek aantal unieke personen zijn vereist om certificeringen of badges op de betreffende MSC te behalen.

Referenties – expertise op het gebied van dienstverlening zijn aangetoond door het verstrekken van klant referenties voor recent voltooide projecten die de ervaring valideren en expertise in een specifiek VMware oplossingen aantonen.


Digital Workspace  

Voor deze competentie is expertise in VMware Workspace ONE en VMware Horizon omgevingen met de daarop juiste levering van services. Het bereiken van deze competentie valideert een technisch inzicht en vermogen tot het ontwerpen en neerzetten van een volledige workspace omgeving op basis van VMware technologie. Een groot onderdeel ik ook het leveren van professionele projecten met Desktop Virtualisatie, Unified Endpoint Management, app-identificatie en toegangs beheer.

Voor meer informatie over onze competenties zie onze partner website bij VMware of neem contact op met ons. Wij helpen u graag verder in de wereld van de moderne werkplek.

Nog niet bekend met ons?

Bekijk onze Mission ONE video hoe wij kunnen integreren met Workspace ONE Access / UEM en uw werk simpeler kunnen maken door middel van VMware Mobile Flows met onze One Click oplossing. Lees hier meer dat VMware voor het derde jaar op rij uitgeroepen tot leider in het Gartner Magic Quadrant for Unified Endpoint Management 2020. Dus heeft u of wilt u een Workspace ONE omgeving of meer zou willen halen uit uw bestaande Workspace ONE omgeving en wilt u daarbij de juiste hulp? Meer weten? Neem contact op met Laurens van Duijn, Technology Evangelist VMware bij RawWorks. Wij helpen u graag verder in de wereld van de digitale werkplek van de toekomst.