Tijd te kort

In verband met te weinig tijd en te veel drukte op het werk ben ik niet meer in staat om mijn blog te schrijven.

Dag 75: Intervisie op school.

Vandaag was er intervisie op school en was ik dus niet aanwezig bij I-Company.

Dag 74: stageverslag en vastgelopen server

Vandaag heb ik naast de normale werkzaamheden hard gewerkt aan mijn stage verslag. Het was vandaag behoorlijk rustig op de afdeling en hierdoor heb ik de tijd gehad om aan mijn stage verslag te werken. Verder was er vandaag nog een issue van een klant waarbij de server voor de tweede keer in 1 week down was. De vorige keer was dit omdat de schijf nog maar 80kb aan ruimte over had. Dit hebben wij toen opgeschoond en alles werkte weer naar behoren. Vandaag was de server weer down en werden wij tijdens de lunch geroepen om te kijken wat er aan de hand was. Nu bleek dat  twee websites bij elkaar meer dan 100% CPU verbruik hadden. Hierdoor liepen alle andere websites vast en was het niet meer mogelijk deze te bezoeken.

Daarnaast heb ik vandaag voor deze zelfde klant een probleem onderzocht. Namelijk dat wanneer er een tekst module aangepast werd met de Rich text Editor oftewel de FCK module van DNN, werd bij het .net portaal niet de groote en het lettertype weergegeven. Na meerdere malen bestanden vervangen en in configuraties kijken is gebleken dat er een css bestand ergens op de website verkeerd geconfigureerd staat waardoor deze twee zaken niet worden weergegeven.

Verder waren er vandaag niet veel issues waardoor er niet veel te vertellen is.

Dag 72: Stageverslag

Vandaag heb ik naast de normale werkzaamheden hard gewerkt aan mijn stage verslag. Het was vandaag behoorlijk rustig op de afdeling en hierdoor heb ik de tijd gehad om aan mijn stage verslag te werken. Verder zijn er vandaag eigenlijk geen bijzondere issues geweest.

Dag 71: Verwijdering van producten en Google indexering

Vandaag was het naast de normale werkzaamheden vrij rustig op de servicedesk. Daarom zijn er niet zo veel belangrijke en noemenswaardige onderwerpen aan bod gekomen. Daarom zal ik enkel over twee onderwerpen iets vertellen vandaag.

Als eerste heb ik vandaag een ticket behandeld van een klant die een vraag had met betrekking tot zijn website beter bereikbaar maken voor Google. Dit is vrij simpel op een DNN website. Dit kan namelijk gedaan worden door bij de pagina settings de sleutelwoorden in te voeren die Google moet vinden wanneer Google de website indexeert. Echter zijn wij erachter gekomen dat de pagina omschrijving ook word meegenomen door Google wanneer Google indexeert. Zelfs de volledige inhoud van de pagina word meegenomen bij het indexeren van de website. Daarom heb ik de klant haarfijn uitgelegd hoe het mogelijk is om zijn website beter bereikbaar te maken voor Google. Er kunnen slechts 15 sleutelwoorden ingevoerd worden die Google meeneemt tijdens de indexatie. Verder kunnen er ook maar 100 characters bij de omschrijving meegegeven worden.

Het tweede ticket ging over een verwijderde productlijn op een pagina. De klant had via het CMS van DNN enkele productlijnen toegevoegd en verwijderd. Per ongeluk had de klant echter een categorie nummer veranderd in een ander nummer. Dit had tot resultaat dat er een complete productlijn niet meer aanwezig was in de webshop. De klant was best geschrokken dat dit per ongeluk gebeurd was. Ik heb daarna samen met en collega in de database gekeken. Na onderzoek bleek dat een hoofdcategorie ID veranderd was en dat die dezelfde ID had gekregen als een sub categorie. Hierdoor was dus de gehele categorie niet meer actief. Ik heb daarom de hoofdcategorie ID weer terug gezet op de originele ID. Nadat deze aanpassing actief was werkte de webshop weer naar behoren en waren er geen problemen meer aanwezig.

Daarnaast heb ik nog allerlei normale werkzaamheden behandeld vandaag zoals FTP users aanmaken, het registreren van domein, met in het bijzonder .xxx domeinen voor klanten die zeker willen weten dat er geen personen zijn die de .xxx domeinen aanschaffen en hier niet legale zaken mee doen. Daarnaast heb ik op het einde van de dag nog een gehele nieuwe omgeving aangemaakt voor een nieuwe website op een acceptatie omgeving. Hierbij moest ook een compleet nieuwe acceptatie database aangemaakt worden.

Gelukkig is het weer einde van de dag!

Dag 70: Datacenter bezoek en installatie nieuwe servers

Vandaag was het in het begin van de dag een rustig dagje. Er waren omdat wij gisteren hard doorgewerkt hebben bijna geen tickets meer aanwezig in de servicedesk. In de ochtend was het aan ons enkel om een PHP website over te zetten van een externe omgeving naar onze interne hosting omgeving. Dit heeft Martijn dan ook in de ochtend gedaan. Ik ben in de ochtend bezig geweest om op alle computers in het bedrijf nieuwe virusscanners te installeren. Dit was heel erg nodig omdat niet op elke PC virus scanners aanwezig waren, of er was een hele oude slechte scanner aanwezig. Dit heb ik in de ochtend op elke PC vervangen. Ik heb op aanbeveling van de directeur Microsoft ForeFront Endpoint Protection uitgerold. Dit is een anti spyware en virus programma wat ervoor moet zorgen dat de werkstations in het bedrijf niet geïnfecteerd raken met spyware of virussen.

Daarna ben ik met Martijn na het Datacenter in Haarlem gereden. Wij hadden van een klant de vraag gekregen of er 2 nieuwe servers en 1 nieuwe switch geïnstalleerd konden worden in het datacenter. Dit is natuurlijk mogelijk en dat hebben wij vanmiddag gedaan. Het was nogal een gedoe om met die gigantische dozen naar binnen te komen in het datacenter, maar uiteindelijk was het toch gelukt. Nadat wij de servers in de rekken gehangen hadden en de powerkabels aangesloten hadden werd al vrij snel duidelijk dat er 2 van de 4 powerkabels niet naar behoren functioneerden. Gelukkig had ik zelf nog enkele andere meegenomen waardoor we deze konden vervangen. Na vervanging van de kabels werkten ze wel weer. Daarna hebben wij ook de switch aangesloten. Dit was nodig omdat de switch die op het moment aanwezig was vol zit. Wij hebben de nieuwe switch dan ook aangesloten op de oude switch en verschillende kabels overgezet van de oude naar de nieuwe switch. Dit was nog wel even puzzelen om het werkend te testen. Op onze laptop die wij meegenomen hebben kregen wij het namelijk niet voor elkaar om de zojuist geïnstalleerde servers te pingen of überhaupt om de gateway te bereiken.
Na een half uurtje puzzelen zijn wij er dan toch uitgekomen en hebben wij op onze laptop internet toegang gekregen. Hierna is de klant ingelicht en gevraagd of de klant de servers ook kon benaderen. Dit was helaas niet zo. Na wat heen en weer gebel en verbinding proberen te maken met de servers bleek dat de servers beide geconfigureerd waren met dezelfde IP adressen. Via de iLO interface was het wel mogelijk om de servers te onderscheiden. Hierna zijn wij weer terug gereden naar het hoofdkantoor en heb ik nog ervoor gezorgd dat de firewall ook volledig naar behoren werkte. Ik heb daar de interne en externe IP adressen aan elkaar gekoppeld in de firewall met NAT rules. Ook heb ik ervoor gezorgd dat de servers extern bereikbaar waren via RDP en HTTP/HTTPS toegang. Dit bleek achteraf ook allemaal te werken.

Al met al een leuk dagje! Nu eerst weer weekend.

Dag 69: Drukke dag op de servicedesk/ migraties

Vandaag was het wederom zoals de rest van de week een zeer drukke dag op de servicedesk. Het begon vandaag allemaal met enkele telefoontjes van klanten waarbij kleine problemen zoals FTP toegang en spam e-mail vrij snel opgelost konden worden. Later in de middag kwamen er wat grotere problemen en projecten binnen die mij aardig wat tijd gekost hebben.

Ik heb vandaag contact gehad met een klant die 2 nieuwe servers bij ons in het datacentrum wil plaatsen. Om hiervoor goedkeuring te geven moest er eerst nagegaan worden of er wel genoeg stroom aanwezig was in het rek. Hiervoor had ik een ticket uitgezet naar het desbetreffende datacenter, maar tot op heden had ik nog geen antwoord ontvangen. Daarna belde vandaag de klant nog een keer met de vraag wat de status van de plaatsing was. Nadat ik de klant had uitgelegd dat er een vraag open stond ivm de stroom die er wel of niet aanwezig is, was de klant al bekoeld. Daarna heb ik gebeld met het datacentrum en bleek er al een antwoord gestuurd te zijn op onze vraag, deze was alleen niet aangekomen bij ons op een of andere wazige manier. Achteraf bleek dat er nog genoeg stroom aanwezig was en hebben wij akkoord gegeven voor aflevering van de servers bij ons op kantoor. In de loop van volgende week zullen deze in het datacentrum geïnstalleerd worden.

Verder ben ik vandaag een aantal uren bezig geweest voor 1 bepaalde klant aan twee verschillende migratie trajecten. Zo heb ik bijvoorbeeld een website die klant gemigreerd naar onze hosting omgeving. Dit op zich is niet zo lastig, alleen had deze klant ongeveer 250 geregistreerde domein namen bij zijn website. Hiervoor ben ik dus ruim een uur bezig geweest om deze van de externe hosting omgeving over te zetten naar onze hosting omgeving. Waarna ik ook nog is ruim een uur bezig ben geweest om de werkelijke website aan de praat te krijgen omdat meerdere modules die aanwezig waren in de website uitgeschakeld moesten worden anders werkte de website niet.

Daarna hoorde ik van mijn operations manager dat de klant vergeten was ons te vertellen dat ook nog vandaag een volledige batch van website migraties geplanned stond. Deze migraties zijn vorige week al gedaan en wij waren aan het wachten op antwoord van de klant of deze websites goed getest waren en er geen wijzigingen meer nodig waren. Mits dit zo was konden wij de sites nogmaals migreren om ze te actualiseren en zo de migratie te beëindigen. De websites waren al getest maar de klant was dit vergeten te melden aan ons, waardoor wij om 3 uur smiddags nog is ~10 volledige websites moesten migreren. Normaal staat hier 6 uur werk voor, maar ik heb mij even snel er doorheen gewerkt zodat wij het morgen iets rustiger hebben omdat vrijdag altijd al een drukke dag is. Hierdoor heb ik de werkzaamheden in ruim 3 uur kunnen doen in plaats van 6.

Al met al wederom een drukke dag. Morgen is het de laatste dag van de week en is het alweer tijd voor weekend.

Dag 68: Explosie op de helpdesk

Vandaag was het wederom een zeer drukke stress volle dag. Aan het begin van de dag begon het al "lekker" met het hondenweer van vandaag. Daarna kwamen wij bij I-Company aan om een geheel geëxplodeerde helpdesk te vinden. Er waren in de nacht ruim 12 tickets bij gekomen. Waarvan soms wel 2 á 3 per klant.
Aan het begin van de ochtend zijn wij daarom hiermee aan de slag gegaan en hebben enkele van deze tickets op kunnen lossen.
1 van deze tickets was bijvoorbeeld het aanmaken van een geheel nieuwe website omgeving inclusief database voor een klant. Nadat ik gevraagd had aan onze sales manager of deze klant uberhaupt wel deze websites "zomaar" bij ons mocht plaatsen bleek al gauw dat dit niet zo was en dat de klant hiervoor extra moest gaan betalen. Onze sales manager heeft dit verder gecommuniceerd met de klant en ik heb deze omgevingen aangemaakt in de tussentijd zodat deze vrijwel direct doorgespeeld konden worden aan de klant zelf.
Verder was er vandaag ook 1 klant die drie tickets vrijwel direct ingezonden had over zijn website. Er waren verschillende delen van een nieuw geïmplementeerde Google Analytics code onjuist. Er werden nog steeds oudere functies gebruikt waarbij de eigenlijke nieuwe code niet eens gebruikt werd. Dit heb ik daarom doorgespeeld naar onze developers samen met een ander probleem van deze klant. De klant had enkele pagina's op zijn website op "no index" gezet. Dit houd in dat zoekmachines die pagina's niet indexeert waardoor je deze niet kan vinden op zoekmachines.

Verder heb ik nog kleine dingetjes voor het bedrijf gedaan zoals FTP accounts aangemaakt bij verschillende klanten en daarnaast heb ik ook veel van de "On Hold" tickets nogmaals beantwoord met de vraag of het al opgelost was of dat er nog actie van onze kant nodig was.

Wij hebben vandaag ook de taak gekregen om een plugin module te installeren bij iedereen in het bedrijf. Een externe partij is namelijk een CRM module bij ons in aan het implementeren en wij hebben de taak gekregen om ervoor te zorgen dat dit bij iedereen in het bedrijf aanwezig is zodat iedereen de nieuwe CRM module kan gebruiken.

Dag 67: SSL certificaten & allerlei kleine problemen

Vandaag heb ik weer een drukke dag achter de boeg! Niet alleen waren er vandaag allerlei kleine problemen aanwezig zowel intern als extern. Er waren bijvoorbeeld vragen om FTP accounts aan te maken, om requests in te schieten bij externe host aanbieders en vragen om SSL certificaten te installeren voor de klant.

Dit laatste ben ik wel eventjes mee bezig geweest. Ik heb een standaard COMODO Secure Site SSL certificaat aangevraagd voor een klant vandaag. Na en tijdje kwam de bevestigingsmail binnen en heb ik het certificaat kunnen bevestiging, anders dan gisteren kwam vandaag wel de e-mail binnen. Heel erg raar aangezien dit nieuwe e-mail account precies op dezelfde manier is aangemaakt als de vorige waar ik gisteren over gesproken heb. In ieder geval lukte het vandaag prima en kreeg ik een .zip bestandje binnen met enkele bestanden. Hierin stonden onder andere de volgende certificaten:

- Root certificaat
- Intermediate Certificaat
- Personal Certificaat

In deze volgorde moesten de certificaten ook geinstalleerd worden want anders ging het niet werken volgens onze SSL provider. Nadat ik dit had gedaan was direct
Het certificaat vervangen en werkte de website naar behoren.

Verder heb ik vandaag nog kleine dingen gedaan voor zowel interne als externe klanten. De meeste hiervan zijn niet noemenswaardig en zal ik daarom niet beschrijven. Vandaag was het wederom hektisch dus ik hoop dat het morgen wat minder is.

Dag 66: Hektische dag! SSL certificaten

Vandaag was het weer een hektisch dagje op de servicedesk. Verschillende klanten kwamen met allerlei problemen waar wij op het eerste ogenblik niet veel mee konden. Later bleek toch dat wij hier best veel mee konden en de problemen zonder veel moeite konden oplossen.

Zo was er vandaag een probleem over een SSL certificaat. Wij hebben onlangs een SSL certificaat aangevraagd voor een website van een klant. Vandaag kregen wij een herinnerings e-mail van de provider, dat het certificaat nog steeds niet bevestigd was. Ik heb naar aanleiding hiervan in allerlei spam filters gezocht naar verschillende e-mail adressen en onderwerpen die te maken konden hebben met de e-mail van de bevestiging. Wij hebben best lang gezocht en hebben niets kunnen vinden in de filters. Naar aanleiding hiervan heb ik verschillende keren gemailed met de provider van de certificaten dat deze e-mail nog niet binnen was gekomen. Deze provider bleef mij keer op keer vertellen dat ik het domein van de provider moest whitelisten want waarschijnlijk bleef de mail hangen achter dit spam filter. Dit was echter helemaal niet zo omdat wij wel vaker SSL certificaten en bevestigings berichten binnen krijgen van deze provider. Op het einde heb ik alsnog het domein gewhitelist en is de bevestigings e-mail nogmaals gestuurd. Echter kwam deze nog steeds niet aan. Ik heb toen met mijn eigen e-mail adres van buitenaf een e-mail gestuurd naar het e-mail account van website. Deze kwam toen ook niet aan dus mijn vermoeden is dat de account buitenstaande e-mail weigert.

Verder ben ik vandaag ook bezig geweest met het uitbreiden van een partitie van een schijf op een linux omgeving van een klant. Hier heb ik al eerder wat over vertelt en daar zijn wij vandaag weer verder mee gegaan. Dit omdat de vorige keer een reboot van de server nodig was om de laatste stappen van het uitbreiden van de partitie uit te voeren. Nadat de server gereboot was konden wij nog steeds niet de partitie vergroten. Naderhand hebben wij het zelfs geprobeerd met een Live Linux  CD waarbij we met een GUI de partitie zouden moeten vergroten. Dit lukte wederom niet en enkele minuten daarna hing de klant alweer aan de telefoon met de vraag waarom zijn server down was, terwijl de klant bevestigd had dat wij de server mochten herstarten. De klant had namelijk opgemerkt dat alle services van hem down waren, zoals MSSQL, Proxy en websites. Nadat wij de server weer online gezet hadden en nogmaals gekeken hadden naar het uitbreiden van de partitie is gebleken dat het om een eerdere ext3 partitie ging. Na onderzoek blijkt dat het NIET mogelijk is om deze partitie uit te breiden.

Helaas dus nog steeds 2 niet opgelost problemen. Morgen is weer een dag!

Dag 65: Lekkere werkdag, domein verhuizingen en meer

Vandaag was het voor de derde dag op rij een mooie rustige werkdag. Er kwamen niet zo heel veel tickets binnen en er waren niet zo heel veel lopende zaken. Hierdoor konden wij rustig werken aan enkele andere zaken die al een tijdje uitgesteld omdat het zo gigantisch druk was.

Vandaag heb ik voor een klant bijvoorbeeld geprobeerd een domein te verhuizen. Een week geleden heb ik al enkele domeinen verhuist voor dezelfde klant. Echter 1 enkel domein kon ik niet verhuizen. Bij onze provider TransIP heb ik eerst gecheckt of het domein verhuisbaar was, dit bleek niet zo te zijn. TransIP gaf mij de melding dat het domein "Niet te verhuizen" was. Hierbij dacht ik logisch na dat een ".com" domein een zogenaamde "Domain Lock" heeft waarbij gezegd kan worden dat het domein "gelockt" is en dus niet verhuist kan worden tenzij de lock eraf gaat. Nadat ik dit terug gekoppeld heb aan de klant heb ik vandaag nadat ik het nogmaals gevraagd had een e-mail gekregen dat de "Domain Lock" eraf was en ik het domein kon verhuizen. Ik heb het dus vandaag nogmaals geprobeerd en wederom kreeg ik de melding dat het domein niet te verhuizen was. Daarom heb ik een ticket ingeschoten bij TransIP en heb ik gevraagd waarom het domein niet verhuisbaar is terwijl de klant de "Domain lock" wel uitgeschakeld heeft. TransIP gaf mij hierop het antwoord dat het domein reeds bestaat in een account van TransIP en het daardoor niet verhuisbaar is. Het domein kan echter wel verhuist worden van account naar account dus daardoor moest de klant een "Interne Push" uitvoeren om het domein naar onze account te verhuizen. Hierbij moesten beide partijen akkoord geven op de verhuizing.

Dit heb ik dus weer teruggekoppeld aan de klant en deze zal het opnemen met hun domein provider. Hopelijk is dit snel opgelost zodat het domein snel bij ons staat.

Verder heb ik vandaag een telefoontje gekregen van een klant van ons die een compleet eigen kast heeft in het datacenter. De vraag van de klant was of zei nog 5 nieuwe servers in hun kast konden zetten, dus of er nog genoeg ruimte, ampere en switchpoorten aanwezig was. Na wat onderzoek is gebleken dat er nog wel voldoende stroom aanwezig was maar niet voldoende switchpoorten meer aanwezig waren. Het betreft namelijk een 24 poort switch welke nog maar 4 poorten in vrij zijn. Aangezien er 5 servers bij moeten komen gaat dit dus niet passen. Ik zal maandag nog even kijken welk specifiek type switch er in de kast hangt en welke de klant kan aanschaffen voor ons om in het rek te hangen.

Maar voor nu eerst lekker weekend

Dag 64: DNN FAQ module problemen

Vandaag was het wederom een rustigere dag op de Servicedesk. Dit omdat wij  eergisteren de schouders eronder gezet hadden en nagenoeg alle openstaande tickets weg gewerkt hebben. Hierdoor is de servicedesk veel overzichtelijker geworden is lopen er niet 20 zaken door elkaar heen. Hierdoor is er alleen niet veel te vertellen over de werkzaamheden van vandaag, behalve 1 vraag van een klant.

Er was namelijk een klant die enkele problemen had met zijn FAQ module van hun DNN website. De klant had namelijk vragen toegevoegd aan 1 van de FAQ modules. Echter stond er voor deze vragen een "Q" en een #. De klant vroeg aan mij hoe zij dit kon weghalen. Dit is echt niet mogelijk door de klant zelf en daarom moest ik de template van deze DNN module aanpassen. Dit bleek een simpele aanpassing te zijn, er moest enkel de [INDEX] en de Q parameter weggehaald worden van de template van de FAQ module.
Verder had deze klant ook de vraag of zij de vragen kon categoriseren. Zodat er op de voorgrond meerdere categorieën aanwezig waren, waarop geklikt kon worden waardoor alle vragen die betrekking hadden op deze categorie zichtbaar werden. Nadat ik nogmaals de FAQ module bekeken had werd al snel duidelijk dat het systeem dat deze klant bij ons gekocht had vrij beperkt was. De klant kon enkel de vragen op de achtergrond sorteren op categorie. Dit werd niet zichtbaar op de voorgrond. Eigenlijk dus een waardeloze functie van het systeem.
De klant had nog een derde vraag over het sorteren van de vragen wat het systeem zelf doet. Namelijk wanneer de klant een vraag aanpaste, kwam deze vraag helemaal bovenaan te staan. De klant vroeg zich af of het mogelijk was om de vragen een vaste plek te geven binnen de module. Zodat deze helemaal niet verplaatsten van plek, de klant vond dit vrij irritant voor zijn eigen klanten. Nadat ik de template had bekeken van de FAQ module werd alweer duidelijk dat het een zeer beperkt systeem was. Er was namelijk enkel mogelijk om te sorteren op Datum (Nieuwste/Oudste) of op Populariteit(Hoog/Laag). Dit is dus helemaal niet wat de klant in gedacht had en daarom kunnen de vragen in de FAQ module dus nooit een vaste plek krijgen in het huidige systeem.

Verder was er vandaag nog een maand meeting, daarna was het tijd om naar huis te gaan.

Dag 63: Zeer rustige dag op de servicedesk

Nadat wij gisteren bijna de volledige servicedesk hebben kunnen wegwerken was er vandaag niet zo heel erg veel te doen. Er zijn vandaag eigenlijk maar in totaal 2 problemen binnen gekomen die Martijn opgelost heeft. Daarom heb ik mij vandaag bezig gehouden met een huidig probleem van een klant met een SSL certificaat. Dit certificaat heb ik onlangs aangevraagd voor deze klant en ik heb onlangs ook de bevestiging gekregen van de uitgever dat het certificaat geverifieerd is. Hierdoor ben ik begonnen met het installeren van het certificaat.

Hierbij heb ik eerst het oude certificaat uit de "Certificates" module verwijderd uit de mappen "Personal Certificates", "Root Certificates" en "Intermediare Certificates". Vervolgens heb ik het certificaat ook uit Internet Information Services verwijderd. Hierna heb ik het certificaat opnieuw toegevoegd aan de "Certificates" module aan de map Personal Certificates. Het kan natuurlijk niet zo zijn dat een "www.blabla" een Root certificaat is. Vandaar alleen de toevoeging aan de Personal Certificate server. Hierna is het certificaat toegevoegd aan IIS en de website herstart. Wanneer ik nu naar de link ga waar het om gaat, krijg ik niet het nieuwe certificaat te voorschijn, ik krijg nogmaals het oude certificaat terwijl het oude certificaat verwijderd is van de server. Dit is natuurlijk niet de bedoeling. Na wat onderzoek ben ik erachter gekomen dat de server meerdere A records heeft met meerdere IP adressen. Dit klopt dus ook niet, want je gaat niet altijd naar het goede IP adres. Ik dacht dus heel slim om die adressen om te zetten in een "TXT" record, waarna deze records als het ware uitgeschakeld zijn. Dan gaan alle web requests dus naar het goede IP adres en zal het in theorie moeten werken.


Morgen maar even testen of dit ook echt zo is dan...

Dag 62: Opruiming tickets in het systeem

Vandaag ben ik weer hartstikke druk bezig geweest! Er waren vandaag weer allerlei problemen binnen de servicedesk die opgelost dienden te worden.
Zo ben ik bijvoorbeeld bezig geweest met de laatste websites overhevelen van een externe klant naar onze interne omgeving toe. Deze klant heeft zoals al eerder gezegd meerdere batches van websites die naar onze omgeving overgeheveld moeten worden. Dit was zover wij weten de laatste batch van websites. Er waren wel enkele uitzonderingen die met toestemming van de klant overgezet moesten worden omdat deze enorm veel HTTP headers bevatte, namelijk ~100. Nadat wij de laatste lootjes gelegd hadden aan deze laatste batch vroeg een collega van de sales afdeling hoeveel websites wij nou eigenlijk ook echt "live" hebben van deze klant. Dit houd in de hoeveelheid websites waarvan ook daadwerkelijk de DNS van is omgezet naar onze servers. Dit bleek na onderzoek erg weinig te zijn. Van de circa 50 websites zijn er slechts 30 ook daadwerkelijk die naar onze servers wijzen.

Verder hebben wij vandaag het ticket systeem opgeschoond. Er stonden ondertussen al weer flink wat tickets in het systeem welke wij behandeld hebben, maar nog geen reactie van de klant op hebben mogen ontvangen. Ons is gevraagd nogmaals achter de klanten aan te gaan in plaats van afwachten wanneer de klant reageert. Dit heeft tot gevolg gehad dat er nu bijna geen tickets meer aanwezig zijn in het systeem omdat vele tickets van klanten ondertussen al door de klant zelf verholpen zijn of in de koelkast is gezet om later nog is voort te zetten.

Verder heb ik vandaag wederom voor een klant een backup gemaakt van een database en de website. Deze website zal vandaag geupgrade worden en de klant wou even zeker weten dat er niets mis kon gaan en dat er een backup aanwezig is bij ons.
Ook hebben wij vandaag onderzoek gedaan naar een vraag in het ticket systeem die betrekking had op het uitbreiden van een intern netwerk bij de klant op locatie. Wij zijn best lang bezig geweest in de firewall van deze klant en hebben erg lang op internet gezocht naar mogelijke oplossingen om een extra IP range te activeren. Echter mocht het niet baten want wij konden niets vinden hierover op het internet. Na wat navragen bij onze collega's is gebleken dat deze klant eigenlijk niet meer bij ons in beheer is. Wij doen voor deze klant niet meer het beheer omdat deze klant hun beheer zelf hebben overgenomen. Wij kijken enkel af en toe met een "schuin" oog naar deze omgeving of de klant het niet omgooit. Na contact met de klant en een uitleg hierover heeft de klant vertelt dat zij het niet anders gewent is dat wij dit voor de klant doen. Daardoor gaan beide partijen nu navragen hoe het zit en wie wat moet doen.

Gelukkig zijn er dus weer een heleboel tickets opgelost en is de servicedesk weer wat leger. Geeft ons ook weer een beetje minder stress! :D

Dag 61: FTP en overzetten nieuwe omgeving

Vandaag ben ik meerendeel bezig geweest voor dezelfde klant. Ik heb voor 1 klant 2 verschillende zaken behandeld.

Ik ben voornamelijk een paar uur lang bezig geweest om een website van de klant te actualiseren op onze interne omgeving. Wij hebben deze website al is eerder over gezet naar onze omgeving. Toendertijd heeft de klant besloten om de website niet geheel over te zetten. Dit omdat deze website ongeveer 6 portalen heeft en allerlei HTTP header "bindings". De klant had gezegd dat hun klant voorlopig geen tijd zou hebben om een website over te zetten van hoster. Vandaag had deze klant wel de tijd en hebben wij daarom de database en de website geactualiseerd op onze eigen omgeving. Na enkele aanpassingen in de web config ( aangezien het een DNN site was ) liep de site nog niet soepel, dit omdat er nog geen URL friendly module was toegevoegd aan de website. Dit betekend dat bijvoorbeeld "/default.aspx", "/default" wordt. Nadat ik deze module heb toegevoegd werkte de website volledig naar behoren. Toen ik de website ging controleren op errors heb ik er nog wel 1 gevonden. Dat was namelijk een error dat plaatjes niet weergegeven werden op de website. Na een klein beetje onderzoek is gebleken dat deze plaatjes "hard coded" aangewezen werden in de database. Het volledige fysieke pad stond gewoon aanwezig in een tabel in de database. Nadat ik de fysieke paden heb aangepast werkte de website 100% naar behoren. Nadat ik dit had terug gekoppeld aan de klant, heeft de klant zelf ook nog de website gecontroleerd en vervolgens ook de DNS omgezet naar onze servers.

Verder heb ik voor deze klant vandaag gewerkt aan een aantal overzettingen van andere websites die horen bij de laatste "batch" van websites die overgeheveld dienen te worden naar onze omgeving.

Ook heb ik voor deze klant een ander probleem onderzocht. Er werd namelijk gemeld dat de klant niet zijn tekst kon veranderen om zijn website. De klant kon niet de "Tekst met opmaak editor" module van DotNetNuke openen. De klant gaf aan het met verschillende browsers geprobeerd te hebben en tevens ook de cache en dergelijke gecleared had. Hierna merkte de klant geen enkel verschil en kon deze nog steeds niet zijn tekst bewerken. Ik heb hiervoor een klein onderzoekje gedaan en heb op 6 verschillende, zowel interne als externe desktops, servers en laptops de desbetreffende website geopend en geprobeerd de tekst te bewerken. Bij ons bleek het zo te zijn dat wij op alle machines de tekst konden bewerken. Zelfs op alle versies  zowel oudere als nieuwere van 3 soorten browsers, Chrome, IE en firefox.
Daarom heb ik de klant het advies gegeven om zijn browser te updaten ( Terwijl het op een oudere versie wel werkte ) of het eens te proberen op een andere machine om problemen te beperken. De klant ging dit advies in werking stellen en zal ons hierop later terugkoppelen.

Verder ben ik ongeveer 2 uur naar Hoofddorp gegaan om 2 externe harde schijven aan te schaffen. Deze externe harde schijven zijn nodig voor een klant die op het moment geen backup optie heeft. Deze klant heeft wel afgesproken met ons dat wij backup mogelijkheid in place hebben. Van de week zal ik naar het datacentrum gaan om deze harde schijven te installeren.

Dag 60: Probleemoplossing

Vandaag was het weer een vrijdag, dat was te merken ook. Er waren constant allerlei "snelle" fixes en releases. Deze waren vaak niet zo "snel" als de developers zeiden en duurden soms wel wat langer.

Verder heb ik vandaag samen met enkele collega's gewerkt aan een oplossing voor een probleem dat een klant had. Hier had ik gisteren ook al over gesproken. Namelijk dat een partitie van een schijf te klein geworden was om bestanden op weg te schrijven. Deze partitie moest dus met 5GB uitgebreid worden naar 15GB. Het probleem echter was dat op een of andere manier de machine de extra toegevoegde ruimte niet kon waarnemen. Toen zijn wij tot de conclusie gekomen dat dit niet mogelijk is, behalve wanneer de machine herstart wordt. Juist dit mocht niet gebeuren van de klant, helaas is en anders onmogelijk en daarom hebben wij contact gehad met de klant. Aan de klant hebben wij deze situatie voorgelegd en gevraagd wanneer wij de server konden herstarten. De klant was hiervan niet op de hoogte en zei dat wij de vraag moesten insturen naar hun helpdesk. Dit hebben wij nu gedaan en wij wachten op de reactie van de klant.

Verder was er ook een klant waarbij geen backup oplossing aanwezig was. Ons was voorgesteld om hier zo snel mogelijk een backup oplossing in te richten. Dit hebben wij vandaag ook een beetje gedaan. Wij zijn naar de stad gereden om meerdere externe harde schijven aan te schaffen om deze vervolgens in de richten zodat wij deze volgende week konden installeren in het data centrum.

Ook heb ik nog gewerkt aan een issue met betrekking tot HTML 404 errors. Een klant van ons heeft enkele sites bij ons draaien waarbij netjes een HTML 404 error word weer gegeven wanneer een pagina niet bestaat. Op enkele websites werd dit helaas niet weer gegeven en de vraag aan ons was om dit alsnog in te stellen. Dit is vrij simpel in te stellen door naar de "properties" van  de te wijzigen site te gaan en daar vervolgens een custom error page in te stellen. Nadat wij dit hadden gedaan was de wijziging doorgevoerd en gaf de website netjes een 404 error weer wanneer er om een pagina gevraagd werd die niet bestond.

Verder heb ik vandaag ook voor een klant verschillende bestandstypes toegevoegd aan de IIS server. Deze klant had de vraag om extra extenties toe te voegen aan de server omdat een website van hun die wij hosten deze bestanden had. Dit kan je vrij simpel toevoegen door een zogenaamde MIME type toe te voegen op server of site niveau.

Verder heb ook voor een acceptatie server die bij ons aanwezig is de FTP server gemaakt. Deze was kapot gegaan sinds iemand hier iets aan veranderd had. Wat bleek nou achteraf, volgens IIS moet men een virtual directory aanmaken met dezelfde naam als de username en ftp site. Tevens moet deze ftp map in de Inetpub/ftproot/LocalUser/XXXX staan. Wanneer dit niet gebeurd. Krijg je telkens de error " 530 user XXX cannot login". Zelfs wanneer alle permissions goed staan ingesteld.

En nu is het dan eindelijke weekend!

Dag 59: Problemen en oplossingen

Vandaag was het een vrij normale dag met niet al te veel requests binnen de helpdesk. Er waren een aantal aanvragen voor nieuwe omgevingen voor nieuwe projecten, dit houd in dat er meerdere SVN's repositorys aangemaakt dienden te worden en meerdere website gecreëerd dienden te worden. Ook was er weer een kleine aanvraag voor een database backup. Deze backup moest extern bij een andere partij aangevraagd worden.

Verder heb ik vandaag nog gewerkt aan twee verschillende zaken, namelijk de volgende:

Gisteren belde een klant mij om een backup te maken van de database en de DotNetNuke omgeving. Dit heb ik direct voor de klant aan de telefoon gedaan. De klant ging namelijk de website upgraden en mocht dit niet goed lopen, dan zijn er backups aanwezig. En inderdaad na enkele uren werd ik weer gebeld met de vraag of ik de backup terug kon zetten. Dit heb ik gisteren dan ook gelijk gedaan voor deze klant.
Deze zelfde klant belde mij vanochtend weer op met de mededeling dat veel aangemaakte foto's en pagina's niet aanwezig meer waren op de website. Na een klein beetje speurwerk, had ik gevonden dat ik per ongeluk de verkeerde backup had terug gezet. Namelijk niet die van gisteren, maar die van enkele weken geleden! Hier was de klant dan ook totaal niet blij mee! Ik heb de klant zo goed mogelijk geholpen en hem ook een zo goed mogelijke oplossing gegeven om het probleem op te lossen. Dit heeft de klant ervaart en hij zei enkel dat  de volgende keer dit niet meer hoeft te gebeuren. Hier geef ik de klant gelijk in. Zo zie je maar weer, een foutje zit in een klein hoekje....

Verder heb ik vandaag ook nog gewerkt aan de installatie van een VeriSign Secure Site SSL certificaat. Ik heb nu eindelijk na enkele weken reactie gekregen van VeriSign dat het certificaat bevestigd is en dat ik hem kan gaan installeren. Deze reactie bleek zo lang uit omdat er onjuist contact gegevens verstrekt waren aan ons toen wij het certificaat toen der tijd gingen aanvragen.
Nadat ik de juiste gegevens binnen heb gekregen kon ik op de server waarop de website gehost word de "Pending request" afhandelen. Hierna kon ik gelijk zien dat het certificaat op IIS niveau prima werkte. Hierna heb ik nog in alle browsers die ik heb zoals Chrome, Firefox en IE getest of het certificaat ook daadwerkelijk werkte. Naar mijn verbazing bleek dit lang niet altijd zo te zijn, het certificaat werd soms wel en soms niet goed weergegeven. Enkele keren kwam het oude certificaat nog steeds naar boven. Ik denk dat dit te maken heeft met zowel browser cache als de cache van de server en van IIS. Hierdoor zal ik nog even wachten tot met het terugkoppelen naar de klant of alles ok is nu.

Verder was er al een aantal weken een issue met een share van een klant. Deze klant heeft een NAS van 5TB staan en op deze NAS staan gedeeltes verspreid over verschillende schijven en shares. Nu heeft deze klant ook een backup share. Deze share is 10GB groot en hierop worden dagelijks de backups op weg geschreven. Alleen was het probleem nu dat de backup bestanden groter zijn geworden dan 10GB. Hierdoor vroeg de klant aan ons of het mogelijk was om deze share te vergroten. Wij zijn nu al een tijdje met deze issue bezig en zijn er met hulp achter gekomen dat het dus een .vmdk betreft wat vergroot dient te worden. Dit houd in dat het een harde schijf van een virtuele machine betreft. Dit kan vrij snel gedaan worden mits je weet hoe dit moet. Ook was dit nog is een Linux server waardoor de partitie ook nog is handmatig vergroot moest worden. Dit heeft een collega van ons uitgevoerd en wij hebben hier meegekeken zodat wij dit voor een toekomstige keer ook zelf kunnen uitvoeren voor de klant. Nadat de extra 5GB ruimte toegekend was aan de partitie kon de partitie uitbreiden. Vervolgens was de partitie 15GB groot en kon de klant gemakkelijk zijn backups laten wegschrijven naar deze share.

Morgen is het alweer vrijdag en de tevens bijna weekend!

Dag 58: Schedulen van tasks

Vandaag heb ik mij het merendeel van de dag bezig gehouden met het aanmaken en schedulen van taks voor een klant. Deze klant heeft bij ons een dedicated server omgeving waarop 1 website draait. De klant had ons gevraagd om voor deze website ( welke 2 databases heeft ) een aantal tasks aan te maken en deze te schedulen. Namelijk de volgende tasks;

- Het backuppen van beide databases naar een Backup folder.
- Het vervolgens inpakken van deze beide databases in een .rar bestand voor  in verband met ruimte besparing.
- Het backuppen van de gehele DotNetNuke omgeving van de website en deze weg schrijven naar een Backup folder in een .rar bestand.

De klant kwam met deze vraag aanzetten en had voor ons ook al een klein script aangeleverd. Dit was een stappenplan om MSSQL database te schedulen voor backup. Dit was mogelijk door een zogenaamde Stored Procedure aan te maken in de Master database, deze stored procedure backupped de geselecteerde databases en zet in het bestandsnaam de datum van de dag dat de database gecreëerd is.
Vervolgens is het de bedoeling dat je een .sql bestand creëert waarin staat welke databases de stored procedure moet backuppen. Hierna hebben wij een .bat bestand aangemaakt wat op de "sqlcm" een commando uitvoert waardoor de stored procedure uitgevoerd wordt.

Wij hebben ook 2 aparte .bat bestanden aangemaakt waarin staat wat winrar moet doen. Zo moet het ene .bat bestand ervoor zorgen dat beide databases gerarred worden en dat in de naam van het .rar bestand de datum komt te staan.
Het andere .bat bestand zorgt ervoor dat de DotNetNuke omgeving van de website geheel gerarred wordt en wordt weggeschreven naar de backup omgeving.

Daarna heb ik al deze tasks gescheduled met Windows Task Scheduler. Dit is een vrij simpel proces waarin je kan specificeren wanneer Windows het .bat bestand aanroept zodat de task uitgevoerd wordt.

Verder heb ik vandaag niet veel gedaan naast natuurlijk de normale werkzaamheden van de helpdesk. Zoals kleine releases en deployment waarbij kleine dingen aangepast dienen te worden.

Dag 57: SSL certificaten

Vandaag was het een vrij rustig dagje op de servicedesk van I-Company. Ik heb mij vandaag vooral bezig gehouden met het aanvragen en installeren van SSL certificaten van verschillende klanten.

Zo heb ik voor enkele websites VeriSign certificaten aangemaakt voor  de klant. VeriSign certificaten vereisen grondige contact en bedrijfs gegevens. VeriSign controleerd deze gegevens ook zeer grondig voordat wij het SSL certificaat krijgen. Eerst scanned VeriSign het hele bedrijf of alle informatie klopt met de informatie dat opgegeven is bij de request voor het SSL certificaat. Vervolgens belt VeriSign het genoemde bedrijf om telefonisch nogmaals te bevestigen of het het juiste bedrijf is. Daarna krijgen wij als technisch contact het SSL certificaat toegestuurd en kunnen wij het configureren op een website. Een VeriSign SSL certificaat kost ook flink wat geld namelijk 225 euro.

Ook heb ik een Comodo InstantSSL certificaat voor een klant aangevraagd vandaag. Dit SSL certificaat is net zo veilig als een VeriSign certificaat alleen betaald men er minder voor. De reden hiervoor is omdat COMODO niet alle gegevens van het bedrijf net zo grondig op de proef stelt als VeriSign. COMODO zorgt ervoor dat de klant een e-mail krijgt met een formulier. Dit formulier dient vervolgens ingevuld en ondertekend te worden door het contactpersoon van het bedrijf en vervolgens weer opgestuurd te worden naar de leverancier van de SSL certificaten.

Ook heb ik vandaag een onderzoek gedaan naar een e-mail adres van klant die niet of bijna niet naar ons kon e-mailen. Zijn e-mail bouncede nagenoeg altijd terug. Nadat ik in de log bestande gekeken had van ons e-mail spam filter, bleek dat het betreffende IP adress geblokkeerd werd met een "Extreme Bad History". Dit kwam omdat een blacklist source het IP adres had opgenomen als spam. Nadat ik gecheckt had op de blacklist website wat voor spam het betrof, bleek duidelijk te worden dat het gebruikte IP adres gebruikt werd voor koreaanse spam. Ik kan niet veel voor de klant verder betekenen in deze kwestie omdat waarschijnlijk de klant zijn PC geïnfecteerd is met een spam virus.

Verder heb ik vandaag weer enkele kleine releases en onderzoekjes verricht die het niet waard zijn om in details uit te leggen.

Dag 56: Vervelende klant en kleine klusjes.

Vandaag was het een beetje een aparte dag. Ik heb zoals ik eerder vermeld heb vrijdag voor een klant een omgeving aangemaakt waarbij deze klant ook verbinding kon maken met onze management studio zodat de klant de database kon aanpassen. In eerst in stantie vond ik dit toch best een apart verzoek, het is namelijk niet gebruikelijk om een database en een  website te ontwikkelen op een live server omgeving. Dit wordt normaliter gedaan via een development server waarna, na goedkeuring, de bestanden overgezet worden op een live server omgeving. Deze klant wou deze weg totaal overslaan en dit gelijk op de live omgeving zelf doen. Hier waren wij niet echt van gediend en dit zal in de toekomst ook niet meer gebeuren. Tot die tijd moest dit nu wel opgelost worden, want het probleem was dat de klant geen verbinding met onze sql server kon maken. Na dit onderzocht te hebben bleek dat onze eigen server niet luisterde naar de poort 1433. Dit is namelijk de poort die MSSQL gebruikt om verbinding van buitenaf toe te laten. Na erg lang zoeken bleek dus dat deze poort überhaupt niet open stond en de server helemaal niet hierna luisterde.

Nadat wij de poort open gezet hadden en een telnet geopend hadden naar de server bleek het redelijk aan te werken en kon de klant hierbij. In de tussentijd kwam de klant al flink klagen dat het zo ongelovelijk lang duurde (2 werkdagen) voordat wij dit in orde hadden. De klant heeft bij ons geen hoge prioriteit SLA en moest dus gewoon achter aan in de rij aansluiten. Dit pikte de klant niet, en ging dus bij ons klagen. Wij vonden het wederom ook niet in orde hoe de klant reageerde en hebben dit doorgespeeld aan onze operations manager die contact zal opnemen met de klant.

Verder heb ik vandaag enkele kleine klusjes opgelost zoals kleine deployments van acceptatie naar productie omgevingen en heb ik enkele omgevingen aangemaakt voor nieuwe projecten. Daarnaast heb ik voor de developers enkele databases restored op een test omgeving.

Verder was er vandaag niet veel aan de hand, waardoor ik niet veel extra's meer te vertellen heb. Ik heb nog wel te horen gekregen dat ik van de week een keer naar het datacentrum in schiphol moet rijden ivm controle en checkups van systemen.

Dag 55: Half dagje

Vandaag was het voor mij een kort dagje, ik ben vanwege prive redenen een paar uur eerder weg gegaan. Vandaag heb ik daarom ook niet erg veel te melden behalve de volgende zaak.

Een klant had gisteren (donderdag) een ticket ingeschoten waar in stond of wij een omgeving kunnen aanmaken voor hun developers op een live- omgeving, daarbij moest ook een database komen in onze Management Studio waartoe hun developers toegang konden krijgen. Ik heb dit geprobeerd op te pakken op de laatste dag van de week. Door heel simpel de IP adressen vanwaar verbinding gemaakt word toe te voegen aan de firewall. Vervolgens heb ik een database aangemaakt en een windows user, een user in de management studio waarbij deze de DBO (database owner) was van de database. Verder heb ik een website omgeving aangemaakt in IIS en heb ik een tijdelijke URL aangemaakt voor deze klant.


Later op de dag heb ik vernomen dat dit nog niet helemaal in orde was, de klant had waarschijnlijk enkele firewall problemen. Dit ligt dus waarschijnlijk niet aan onze kant. Maandag zal hier verder over gesproken worden.

Voor nu... Een kort dagje en weekend.

Dag 54: Gebruikersprofilen via domein toevoegen en mssql aanpassingen

Vandaag ben ik naast de normale werkzaamheden vooral bezig geweest met 2 verschillende zaken. Namenlijk als eerst het aanmaken van nieuwe users, toevoegen van deze users aan de VPN verbinding en het aanmaken van een gebruikersprofiel van deze domain users op een andere pc.

Een klant van ons vroeg ons om enkele nieuwe gebruikers toe te voegen aan het netwerk. Dit was niet zo een groot probleem omdat dit simpelweg via AD Users and Computers toegevoegd kan worden. Verder vroeg de klant ook nog is om deze users via hun eigen VPN toegang te geven aan hun netwerk via een externe bron. Na een klein half uurtje zoeken in de firewall had ik dit ook gevonden en heb ik deze users toegevoegd aan de VPN verbinding. Daarna was het de bedoeling om voor deze nieuwe gebruikers een bureaublad aan te maken met hun gebruikersprofiel op basis van dezelfde rechten van een andere aangewezen gebruiker. Dit was toch iets moeilijker dan ik dacht. Na erg lang zoeken ben ik erachter gekomen dat je via Eigenschappen van Deze Computer > Geavanceerd > Gebruikersprofielen kon kijken welke gebruikersprofielen er aanwezig zijn op de lokale machine. Helaas waren de nieuwe gebruikers hier nog niet op aanwezig. Na wederom lang zoeken heb ik maar geprobeerd om zelf even in te loggen met de nieuwe gebruikers op de server. Nadat ik dit had gedaan waren spontaan enkele gebruikers profielen toegevoegd aan de server. Vervolgens kon ik deze kopieren en de goede rechten geven die zei nodig hebben.

Het tweede probleem waar ik grotendeels van de dag mee bezig ben geweest is het aanmaken van een nieuwe omgeving voor een klant. Deze klant heeft onlangs een website laten ontwikkelen en wil deze nu testen. Dit wou de klant doen door middel van deze te hosten bij ons op een server van hun waarbij ze dan vervolgens FTP toegang zouden krijgen tot deze site, om bestanden te uploaden. Ook wou de klant MSSQL toegang hebben tot de database die bij deze website zou horen. Ik heb dit kunnen doen door een SQL authentication user toe te voegen in de security logins van MSSQL. Waarna deze user vervolgens toegevoegd word aan de desbetreffende database.  Dit lukte redelijk, ik kon verbinding maken met de SQL server van deze desbetreffende server, alleen kon ik ook in alle security roles en management tools en settings van de SQL server. Dit is natuurlijk niet de bedoeling. Tevens kon ik alle aanwezige databases zien, maar deze kon ik niet openen. Dit is natuurlijk wel goed maar ik heb liever ook nog dat de gebruiker de aanwezige databases ook niet ziet. Na overleg met een college is gebleken dat dit mogelijk was en hebben wij dit dan ook uitgevoerd.

Ik heb ook nog gewerkt aan een grote release op een productie omgeving vandaag. Deze release is de afgelopen dagen al meerdere malen voorbij gekomen. Echter was hier telkens iets mis mee waardoor dit nog niet doorgeschoven kon worden naar een echte productie omgeving. Vandaag heb ik daarom met de developers om de tafel gezeten om te kjiken of we snel de problemen konden oplossen. Dit is gelukkig snel gelukt en voor het einde van de dag had ik de release alsnog deployed.

Morgen is het alweer vrijdag en is het de laatste dag van de week!

Dag 53: installatie nieuwe server in het cluster

Vandaag heb ik naast de normale werkzaamheden zoals releases deployen ook nog enkele andere werkzaamheden verricht. Zo heb ik bijvoorbeeld voorbereidingen getroffen om een compleet nieuwe server te installeren op het interne netwerk.

Ik heb allereerst gezocht naar een VMWare ESX machine waarop ik deze nieuwe Omgeving op zou kunnen draaien. Dit duurde vrij lang omdat ik geen machine kon vinden waarop uberhaupt nog harde schijf volume of RAM geheugen beschikbaar was. Na een tijdje zoeken heb ik toch nog een ESX machine gevonden waarop nog ruim 300 GB aan hardeschijf ruimte over was en ongeveer 8 GB aan RAM geheugen.

Hier heb ik vervolgens een nieuwe machine in aangemaakt en heb ik Windows server 2008 x64 R2 geinstalleerd. Nadat de installatie voltooid was heb ik enkele functies van de server aangezet zoals RDP( Remote Desktop Protocol ), UAC uit gezet en de server aanmelden in het domein van I-Company.

Vervolgens heb ik enkele basis programma's zoals WinRar en. .Net 4.0 geinstalleerd. Hierna heb ik ervoor gezorgd dat IIS( Internet Information Services ) geinstalleerd werd met de juiste modules. Toen was ik van plan om SQL 2008 R2 te installeeren alleen kreeg ik toen allerlij errors met betrekking tot de ruimte op de server, terwijl er nog ruim 80 GB beschikbaar was op de harde schijf. Hier zal ik morgen verder naar kijken.

Verder is mij ook opgevallen tijdens dr configuratie van de server, dat er intern geen IP adressen meer over zijn van onze internet provider. Dit houd in dat ik geen NAT kan toepassen op de nieuwe server, waardoor deze dus niet te bereiken is via de buitenwereld... Dit probleem zal ik ergens dezen week voorleggen aan de operationele manager.

Vandaag was er ook een klant die telefonisch kwam melden dat hij al zijn servers niet meer kon bereiken en dat bij hem alle alarm bellen afgingen. Terwijl ik telefonisch met de klant ging kijken in ons monitor panel bleken wij niets verkeerds te zien wat vrij raar is. Terwijl wij aan het kijken waren kreeg ik van het datacentrum een email waarin stond dat er enkele problemen aanwezig zijn en dat zij daar druk mee bezig zijn. Nadat ik dit aan de klant vertelde nam deze hier genoegen mee en hing op. Tegelijkertijd zij hij dat alle servers het weer deden. Dus waar het nou aan gelegen heeft is ons in ieder geval nog onduidelijk masr gelukkig was het opgelost.


Verder was er vandaag weer een last minute release voor een grote klant. Deze moest nog rven snel uitgevoerd worden om 2 voor 5...

Dag 52: E-mail problemen en uitvallend internet

Vandaag was het een vrij rustige dag op de helpdesk. Ik heb mij vandaag vooral bezig gehouden met kleine problemen. Onder andere het dagelijkse werk zoals het deployen van releases naar productie of development omgevingen. Ook heb ik weer enkele releases gedeployed voor grote klanten waarbij het nodig was een request in te dienen.

Verder heb ik mij vandaag bezig gehouden met het beantwoorden van de klanten. Vandaag waren er verschillende klanten die enkele problemen hadden met hun e-mail. Als eerste was er bijvoorbeeld een klant die geen e-mail meer kon versturen. Nadat ik enkele vragen had gesteld aan de klant was het al vrij duidelijk wat het probleem was. De klant had onlangs een nieuwe pc aangeschaft voor op zijn bedrijf. Toen de klant zijn e-mail ging instellen heeft de klant de automatisch instellingen meegenomen. Wat als resultaat had dat de klant zijn smtp instellingen verkeerd had ingesteld. De klant had namelijk smtp.kpn.nl in zijn e-mail instellingen in plaats van het smtp adres van I-Company. Nadat ik de klant zijn goede e-mail instellingen gegeven had kon de klant weer e-mail versturen. Verder was er ook nog een probleem dat een klant geen e-mail kon versturen, deze klant vroeg zich af of de e-mail ergens in het spamfilter bleef hangen. Dit bleek niet zo te zijn en dit heb ik aan de klant gecommuniceerd. Iets later belde de klant terug dat het nog steeds niet werkte. Ik heb daardoor een half uur met de klant aan de telefoon gehangen om alle eventuele problemen op te lossen. Dit verliep niet soepel dus daardoor heb ik via teamviewer de klant geholpen. Uiteindelijk heb ik het probleem achterhaald, het had te maken met een nieuw geïnstalleerd anti virus programma wat de outlook client bleek te weigeren en alle inkomende mail bleek tegen tehouden. Nadat ik dit in het programma uitgezet had bleek alles weer naar behoren te werken.

Verder was er vandaag ook nog een interne internet storing. Het internet lag op het hoofdkantoor van I-Company eruit. Nadat wij in de server ruimte gecontroleerd hadden of er iets aan de hand was bleek er niets aan de hand te zijn en waren wij eigenlijk een beetje radeloos. Nadat ik ben terug gelopen naar mijn PC bleek dat het internet alweer werkte. Hierna krijgen wij wel enkele vragen van klanten die onze Uptime monitor niet konden bereiken. Nadat wij de situatie uitgelegd hadden aan de klant, waren de klanten tevreden met onze uitleg.

Verder was er ook weer een issue met een IBM pakket van een klant vandaag. De klant kreeg geen response meer wanneer hij naar zijn IBM pakket ging. Toen ik deze IBM service ging restarten bleef de service hangen en daardoor heb ik de gehele server herstart. Later ging ik vragen bij een collega wat voor support wij bieden aan deze klant, het bleek dat wij alleen de OS bieden aan deze klant en de applicatie zelf door IBM beheerd word. Hierdoor word dit doorgeescaleerd naar de sales consultant die contact op neemt met de klant over de volgende stappen.

Dag 51: Problemen oplossen

Vandaag begon de dag rustig, ik heb gewerkt aan enkele kleine releases voor zowel intern als extern. Nadat de tijd vorderde kwam nog een vraag binnen of wij het volume van een NAS share konden verhogen van 5 GB naar 15 GB. Na een kleine inspectie op de interface van de NAS zijn wij tot de conclusie gekomen dat de NAS al volledig ingedeeld is. Omdat dit een Netgear NAS betreft en dit een specifieke versie is, is het niet mogelijk om naderhand volumes van shares te verhogen! Een andere oplossing zou kunnen zijn om een nieuwe share aan te maken op de NAS ( Deze heeft namelijk nog ruim 2 TB aan ruimte over ), waarna vervolgens alle data overgeheveld kan worden van de originele share.
Vervolgens moet de nieuwe share hernoemd worden en de oudere verwijderd worden. Dit neemt wel enkele consequenties met zich mee zoals downtime van de originele share. Ook moeten enkele processen gestopt worden die data weg schrijven. Hierbij kan je denken aan MSSQL of MySQL databases. Als deze niet kunnen stoppen, dus wanneer er geen downtime kan zijn bij de klant, is het helaas onmogelijk.

Verder heb ik vandaag verscheidene domeinen aangemaakt door middel van de tool die I-Company gebruikt. Daarnaast heb ik weer voor allerlei klanten updates gedeployed voor hun websites. Hier onder vielen ook weer enkele grotere klanten waarbij de hosting omgeving in Indonesië staat waardoor een request ingediend moest worden om de release te deployen.

Dag 50: Laatste dag van de week

Vandaag was het weer de laatste dag van de week! Het was vandaag een vrij normale dag met enkele releases die weer net op het laatste moment op de productie omgevingen geplaatst moesten worden.

Verder is er vandaag nog een issue geweest met een IBM websphere product van een klant. Het product was niet meer bereikbaar, waardoor de klant met de suggestie kwam om de websphere service of de server te herstarten. Nadat ik dit gedaan had, was de website wel weer bereikbaar alleen was kreeg ik nu een mooie java 500 error. Deze error is niet te vinden op het internet en nog nooit heeft iemand hiermee problemen gehad. Deze issue staat dus nog open. Maandag zullen wij een expert vragen of hij dit probleem kan oplossen.

Verder was er vandaag een probleem met het insturen van deployment aanvragen aan een externe hosting omgeving van een externe partij. Wij kregen telkens de aanvraag terug, waar in stond dat wij iets verkeerd hadden gedaan en gelieve dit nu goed in te sturen. Na een aantal e-mailtjes heen en weer heb ik besloten om de servicedesk zelf te bellen om te kijken wat wij nou precies verkeerd aan het doen waren. Uiteindelijk bleek dat wij zelfs niets verkeerd gedaan hadden maar onze contactpersoon bij de externe partij. Deze had niet de aangewezen template gebruikt voor het insturen van de aanvraag. Dit zal nu door onze sales afdeling gecommuniceerd worden met de externe partij.

Verder hebben wij nog enkele aanpassingen in de firewall gedaan vandaag zodat een klant via zijn thuis IP adres in zijn server kon.

Het einde van de dag was net zoals gisteren, allerlei releases die op het laatste moment op de productie omgevingen gezet dienden te worden. Gelukkig is hierbij weer alles goed gegaan.

Dag 49: Drukke dag op de servicedesk met veel spoedjes

Vandaag was het een vrij drukke dag op de servicedesk. In de ochtend begon het nog langzaam met enkele tickets om bestande te deployen op live omgevingen en acceptatie omgevingen. Al gauw kwamen daar tickets bij van klanten die geen bestanden en links op hun websites konden plaatsen. Deze kwestie heeft Martijn opgepakt.

Ik heb ook nog enkele tickets behandeld van klaten die graag wilden weten welke keywords men het beste in hun CMS systeem zouden kunnen zetten zodat deze correct gevonden kunnen worden via google. De klant gaf aan dat zij al meerdere keywords heeft ingevoegd maar dat deze nog niet goed gevonden werden op google. Na een klein onderzoek bleek dat de klant de keywords incorrect had ingevoerd in haar CMS systeem. Nadat ik deze alsof correct heb ingevoerd konden ze alsnog niet gevonden worden via google. Dit komt omdat google niet direct indexeerd welke woorden gevonden moeten worden. Dit kan enige tijd in beslag nemen.

Verder heb ik tijdens het einde van de middag erg veel tickets behandeld van 3 verschillende grote klanten. Van deze drie klanten moesten toevallig 3 websites online gezet worden. Dit duurde allemaal vrij lang omdat de developers nog niet geheel klaar waren met het programmeren van verschillende functionaliteiten die het programma wel diende te hebben. Eindelijk rond 17:00 uur konden alsnog alle drie de websites op een live omgeving gezet worden. Hierdoor diende er eerst omgevingen aangemaakt te worden en verschillende domeinen geregistreerd te worden bij een registrar.

Verder is er vandaag niet veel speciaals gebeurd. Morgen is het alweer de laatste dag van de week!

Dag 48: Nieuwe omgevingen aanmaken en troubleshooten

Vandaag heb ik me vooral bezig gehouden met het aanmaken van omgevingen voor development afdelingen en live afdelingen. Naar aanleiding van het krijgen nieuwe projecten binnen het bedrijf moesten verschillende omgevingen aangemaakt worden.

Verder heb ik een een aantal tickets opgelost die te maken hadden met troubleshooten van problemen die die klant ondervond. Bijvoorbeeld het bekijken waarom e-mails niet aankomen bij een persoon. Hiervoor heb ik in het spamfilter gekeken en gezocht naar het e-mail adres. Hier bleek uit dat het e-mail adres vanwaar e-mails gestuurd waren niet op een spam lijst stond. Er stond namelijk duidelijk voor het e-mail adres "NOTSPAM". Het probleem lag dus bij de persoon die de e-mail ontvangt.

Verder heb ik vandaag enkele tickets behandeld die betrekking hadden tot het naar een staging omgeving deployen van files. Waarna deze files naar een live omgeving gezet konden worden via een aanvraag bij de party die de hosting verzorgde.

Daarnaast heb ik voor een klant een nieuwe website aangemaakt en deze goed ingesteld in IIS met de juiste configuratie, waarbij er ook een FTP gebruiker toegevoegd moest worden aan de Default FTP site. Dit kan gedaan worden door middel van een virtual directory toe te voegen en vervolgens de zojuist aangemaakte FTP gebruiker rechten op de map te geven.

Als laatste heb ik ook nog voor een klant in de firewall een extra regel toegevoegd, zodat deze klant toegang heeft tot zijn MSSQL database die wij beheren voor hun. Deze klant wou dat de development omgeving ook toegang kreeg tot de MSSQL database. Hierdoor heb ik een IP adres gewhitelist en toe gevoegd als ACL. Hierna had de klant zijn development omgeving toegang tot de MSSQL database.

Dag 47: Opruimen van de servicedesk

Vandaag was het de dag van het opruimen van de servicedesk. Vandaag heb ik samen met Martijn de tickets die nog open of op on hold stonden in het systeem verwerkt. Ik heb onder andere gewerkt aan tickets die van een kroatische partij afkomstig waren. Deze had geen problemen ondervonden maar had wel errors gespot en deze tot onze aandacht gebracht. Er was een error waarbij windows de melding gaf dat de SQLresourcelocater.dll niet aanwezig was in het systeem. Nadat ik dit heb onderzocht bleek dat dit komt omdat er enkele componenten van SQL 2005 niet geïnstalleerd waren op de aanwezige server. Een andere oplossing is om simpel de server te restarten, dit is helaas niet mogelijk in verband met de vele websites die op deze server draaien.

Verder waren er vandaag normale deployment tickets die ik heb verwerkt. Verder heb ik vandaag zelf bij TransIP een ticket ingeschoten om opheldering te krijgen over een .fr domein wat ik voor een klant moest registreren bij I-Company. Hier ben ik zelf al een tijdje mee bezig en ik kwam er maar niet uit omdat TransIP een error bleef geven dat te maken had met een zogenaamde "trustee" service die niet beschikbaar was voor dit domein. Nadat ik contact heb gehad met TransIP bleek dat het .fr domein niet op gegevens van I-Company geregistreerd kon worden maar enkel op de gegevens van hun trustee. Het domein is uiteraard wel in ons beheer en van ons, maar geregistreerd via de trustee van TransIP.  Nadat ik heb vernomen dat  de trustee mijn aanvraag nu zal goedkeuring heb ik de aanvraag wederom ingediend.

Verder heb ik samen met Martijn nogmaals gekeken naar een VPN verbinding die wij bij een klant hebben om bestanden te deployen op live omgevingen. Achteraf bleek dat het een simpele fout bevatte en wij konden eindelijk weer verbinding maken met de klant zijn omgeving.

Op het einde van de dag kregen wij nog een verzoek om een backup terug te zetten en hebben wij onderzocht hoe dit in elkaar zat in het datacenter in haarlem. Dit bleek nog niet zo makkelijk aangezien het totaal niet gedocumenteerd was, nadat wij geraadpleegd hebben bij een collega kwam deze ons helpen om de vraag van de klant te beantwoorden. Naar aanleiding van dit onderzoek bleek dat onze VMWare backup procedure niet meer gewerkt heeft sinds 1 november!! Dit kwam omdat VMWare de backups "lockte" en vervolgens niet meer uitvoerde omdat de backup bestanden gelockt zijn. Deze waren gelocked omdat VMWare niet meer een integrity check kon uitvoeren op deze bestanden. De oplossing hierbij was het .lck bestand te verwijderen in een map van VMWare en de service te herstarten. Dit was ook nog een flinke taak omdat er dit wederom niet gedocumenteerd was. Toch is het ons gelukt en is VMWare bezig om de bestanden een integrity check te geven.

Morgen willen wij proberen alle tickets in het systeem die nog niet behandeld zijn te behandelen, ook zullen wij van plek wisselen morgen.( Ander bureau )

Verder ga ik proberen te kijken of wij verder kunnen gaan aan ons deployment project.

Dag 46:

Vandaag ben ik thuis gebleven in verband met sterfte in de familie. Morgen weer op HQ aanwezig!

Dag 45: Verhuizingen van domeinen en vage problemen van klant

Vandaag heb ik gewerkt aan verschillende tickets die nog open stonden. De eerste paar tickets gingen over een aantal verhuizingen van domeinen van een externe partij naar ons. Dit hebben wij ook al enkele geprobeerd waarbij geen resultaat. De verhuizingen duurden veel langer dan normaal en wij dachten dat wij iets verkeerd hadden gedaan. Dit bleek niet zo te zijn. De verhuizingen duurden zo extreem lang ( enkele dagen ) omdat de huidige houder van het domein zijn e-mail niet had gelezen en dus niet geaccepteerd had dat het domein verplaatst werd. Nadat wij de huidige houder gebelt hadden waarbij zij hun bevestiging gegeven hadden zou het domein verplaatst moeten zijn. Dit was helaas aan het einde van de dag nog niet gebeurd. Wordt dus vervolgd...

Verder heb ik ook gewerkt aan een aantal problemen van een klant van ons. Deze moest ook weer enkele domein namen registreren bij ons. Deze domein namen waren geen enkel probleem op een frans domein na. Dit domein vereiste een Frans domiciel adres ( Frans vestigingsadres ). Nadat wij dit gekregen hebben van de klant hebben wij dit domein geregistreerd. Helaas ging dit fout. Er kwam een error naar voren dat de "trustee" niet goed was. Word dus ook nog vervolgd. Verdere problemen van de klant waren links die het niet deden om hun websites en een gastenboek waarbij een aantal beoordelingen aanwezig hoort te zijn die er nie waren. Na onderzoek is gebleken dat de klant zijn eigen gastenboek kan bewerken en dacht ik dus dat die aantal beoordelingen statisch bleek te zijn. Dit was niet zo en moest dus dynamisch zijn, nadat ik aan een collega gevraagd had hoe dit zat, bleek dat de klant zelf zijn eigen HTML code heeft aangepast en dus het hele stuk code verwijderd had, wat er eigenlijk voor zorgt dat dit aantal beoordelingen dynamisch is.

Vanavond gaan wij lekker uit eten en lekker drinken in Haarlem! Daarna weekend.

Dag 44: Wederom een rustige dag op de servicedesk

Vandaag was het wederom een rustige dag op de servicedesk. Er zijn niet veel tickets binnen gekomen en die die wel binnen gekomen zijn konden wij simpel oplossen of met een beetje navraag oplossen. De volgende tickets schoten er wel boven uit±

Een ticket ging nogmaals over de VPN verbinding van een klant die nog steeds niet werkte. Wij konden hier verder niets meer mee doen omdat het balletje bij de klant zelf lag nu. Wij hadden alles onderzocht en hadden de firewall op zijn kop gehouden, waarbij aan onze kant niets mis bleek te zijn. Toen is de klant zelf gaan onderzoeken of bij hun wat fout is gegaan. Dit bleek ook zo te zijn, de klant had hun vaste werkstations via een switch naar buiten lopen. Deze switch bleek data te encrypten waardoor de VPN de data niet goed herkende en dus zodoende geen verbinding met de oracle server gemaakt kon worden. Wij hebben van onze meerere te horen gekregen dat wij supergoed met deze situatie zijn omgegaan, wij hebben alles accuraat en snel opgepakt en de klant waar mogelijk geassisteerd. Wij hadden van deze klant eigenlijk geen kennis en toch hebben wij het probleem opgelost. Daar was onze meerdere zeer tevreden over, en de klant ook. Waardoor de klant waarschijnlijk zelfs nog meer servers bij ons zal gaan kopen!

Verder heb ik me ook bezig gehouden met het probleem van een klant die geen e-mail kon versturen. Nadat wij met de klant gecommuniceerd hadden dat deze klant van elke PC op de vestiging een virus scan naar ons toe moest sturen, hebben wij deze e-mail adressen die op die PC's huisvestte op de white list gezet. Waardoor de e-mail van deze klant niet als spam gemarkeerd zou worden en dus gewoon verstuurd zou worden.

Morgen weer een dag en morgen gaan wij ook mee op een bedrijfsuitje! Leuk!

Dag 43: Rustige dag op de servicedesk

Vandaag was het nogmaals een rustige dag op de servicedesk. Er zijn vandaag een speciale verzoeken langs gekomen op 1 na.

Er is bij ons een klant die namelijk geen interne mail meer kan versturen. Na het raadplegen van de log bestanden is gebleken dat de klant een virus op hun systeem aanwezig hebben. De klant heeft enkele tientallen vestigingen en hun mail gaat via ons. De telefoon stond vandaag roodgloeiend van deze klant. Wij hebben bijna alle vestigingen aan de telefoon gehad dat zei geen interne mail konden versturen. Na enkele malen met mijn collegas's geraadpleegd te hebben, zijn wij tot een kleine oplossing gekomen.

Wij zullen de e-mail adressen van de desbetreffende vestigingen en machines white listen ( dit houd in het goedkeuren van de e-mails die van deze e-mail adressen komen ) wanneer de klant een screenshot van een virus scan laat zien aan ons. Nadat wij kunnen zien dat er geen virus aanwezig is op dat desbetreffende systeem zullen wij deze white listen en kan deze klant weer e-mail versturen.

Verder is er vandaag niet vel speciaals gebeurd. Hopelijk is het morgen wat interessanter!

Dag 42: Nogmaals rustige dag

Vandaag heb ik mijn normale werkzaamheden gedaan binnen de servicedesk. Enkele tickets hadden te maken met standaard procedures voor het live zetten van bestanden voor klanten.

Vandaag was het behoorlijk rustig aangezien wij de afgelopen dagen veel tickets weg gewerkt hebben in het ticket systeem. Toch sprongen twee tickets eruit.

De eerste had te maken met enkele VPN instellingen van een klant. Wij beheren een website voor een klant maar deze website wordt elders gehost. Als er wijzigingen aangebracht moeten worden voor deze website moet dit eerst gecommuniceerd worden aan de IT afdeling van de brand. Daarna gaat dit naar de servicedesk van de hosting partij waarna die de change uitvoerd. Dit is dus een zeer onnodig lang proces. Wij hebben hiervoor een VPN zodat wij toegang tot de test omgevingen hebben van de klant. Deze VPN deed het niet meer, na wat e-mail verkeer blijkt dat de VPN gegevens veranderd waren en niet aan ons door gecommuniceerd waren.

Verder was er nog een probleem met een firewall issue van een klant die ik opgelost dacht te hebben van de week. Dit was toch niet het geval, er was nog steeds een probleem. Na enkele uren beraad met een externe expert is gebleken dat het waarschijnlijk toch bij de klant ligt.

Vandaag heb ik mij ook bezig gehouden met een website migratie, hier ben ik het merendeel van de dag mee bezig geweest.

Verder was er vandaag niet iets belangrijks, morgen weer een dag.

Dag 41: Rustige dag

Vandaag was het wederom een rustige dag op de servicedesk. Omdat wij vrijdag bijna alle tickets opgelost hadden, hadden wij vanochtend niet direct tickets om aan te werken. Hierdoor heb ik mij verdiept in enkele van de tickets die open stonden. Deze betrof ook het aanmaken van e-mail adressen voor een klant, het deployen van bestanden naar een acceptatie of live omgeving. Dit waren natuurlijk de simpelere tickets, hiernaast was ook 1 moeilijker ticket namelijk het wijzigen van een IP adres van een server.

In ieder geval zei de klant dat er een IP adress van een website veranderd moest worden. Na heel lang zoeken, waarbij ik de opgegeven IP adressen nergens kon vinden bij I-Company heb ik met een collega de boel geraadpleegd. Hieruit bleek dat dit wel degelijk bij ons aanwezig was, alleen dat het om een IP toegangs adres van een FTP account ging! Dit is aan te passen in IIS bij de default FTP website. Wat blijkt nou, windows denkt vrij invoudig. Wanneer een useraccount van de server dezelfde naam heeft als de FTP website in IIS, dan koppelt windows dit automatisch. Hierbij is het mogelijk om IP adressen te stellen vanaf waar een gebruiker toegang heeft tot de FTP site. Nadat dit opgelost was heb ik met de klant terug gekoppeld dat het probleem opgelost was. Die was hier heel blij mee.

Verder hebben wij nog een website gemigreerd naar een ander datacentrum.

Maar nu eerst, tot morgen

Dag 40: Stage beoordeling en afwerking tickets.

Vandaag heb ik met enkele collega's van de afdeling erg veel tickets afgehandeld die nog open stonden in de servicedesk. Enkele tickets waren zelfs al 3 weken oud, waardoor er met de klant afgestemd moest worden of het probleem uberhaupt nog wel bestond of dat het ondertussen al opgelost was. Van veel van de tickets was het probleem al opgelost en konden de tickets mooi geclosed worden. Van de andere tickets diende er nog informatie van de klant toegevoegd te worden voordat wij hier iets mee konden doen.

Hieronder viel ook het verhuizen van een extern domein naar onze interne omgeving zodat wij deze in beheer konden nemen en de website konden verhuizen. Onder andere heb ik ook nog DNS wijzigingen doorgevoerd en enkele log bestanden geraadpleegd voor de klant zijn problemen.

Nadat wij dit gedaan hadden was het tijd voor de tussentijdse beoordeling van onze stage bij I-Company. Samen met onze stagebegeleider van I-Company en van school hebben wij de beoordeling ontvangen. Er was bij mij eigenlijk 1 puntje wat iets beter kon en de rest was allemaal al perfect. Onze begeleider van I-Company zei zelfs dat als wij geen opleiding zouden volgen hij ons zo zou aannemen. Daarmee zei hij ook nog dat wij goed liggen in de organisatie en dat iedereen erg tevreden over onze inzet en motivatie is, wij werden zelfs "helden" genoemd voor onze hoge inzet! Dit vind ik een heel erg mooi compliment en ik zal hier ook voor zorgen dat dit hetzelfde blijft! Kortom, ik ben blij dat I-Company erg tevreden over ons is!

Nu is het weekend

Dag 39: Stagepresentatie

Vandaag heb ik mijn stage presentatie gehouden op school. Het uiteindelijke cijfer dat ik hiervoor ontvangen heb was een 7.5.

Dag 38: Rustige dag

Vandaag was de laatste dag dat onze begeleider aanwezig was op de afdeling. Na vandaag begint deze bij een andere baan waar ik hem veel plezier wens!


Verder heb ik vandaag zoals altijd enkele tickets afgewerkt die in het systeem waren. In het bijzonder betrof dit een paar tickets die aandacht van de klant nodig hadden. Zoals het oplossen van e-mail problemen en het uitzoeken van mail logs. Verder was er ook een grote klant die geen verbinding met zijn Oracle server kon maken via de VPN die de klant heeft met hun servers bij ons. Hier heb ik mij het meeste van de dag mee bezig gehouden. Ik heb mij hiervoor verdiept in de Cisco ADSM GUI software voor hardwarematige Cisco firewalls. Hieruit heb ik aan het einde van de dag enkel 1 ding gevonden en dat is dat de klant een ander netwerk is gaan gebruiken waardoor de klant niet meer kon verbinden met de server.

Verder is er vandaag niet veel gebeurd en zal ik morgen mijn stagepresentatie geven op school.

Dag 37: Redelijk rustig dagje

Vandaag was het een redelijk rustig dagje op de servicedesk. Onze begeleider is zoals eerder verteld niet meer actief op de afdeling. Deze zal alleen nog maar assisteren via de zijlijn. Vandaag hebben wij veelal normale service requests op de helpdesk uitgevoerd.

Enkele verzoeken kwamen er bovenuit omdat ik regelmatig contact moest hebben via de telefoon met klant. Bijvoorbeeld was er een klant die een eigen VPN verbinding heeft met zijn servers. Deze klant kan verbinding maken met hun servers op Windows niveau, maar niet op Oracle niveau. Dit betekend dat de klant geen verbinding kon maken met zijn Oracle server. Dit vond de klant niet prettig omdat deze zat met een oplevering van een product dat nu uitgesteld moest worden. De klant suggereerde dat het aan onze firewall zou liggen dat ze wel verbinding op Windows niveau hadden maar niet naar hun Oracle services. Dit is dus absoluut niet waar omdat VPN geen specifieke services blokkeert. Het is of alles wordt toegelaten of niets. Na een lange uitleg aan de klant was die nog steeds niet tevreden omdat het programma nog niet werkte. Ik heb hiervoor overlegd met een andere collega en samen hebben wij vragen bedacht voor de klant die hij moest beantwoorden voordat wij verder konden met het probleem. Tot op heden nog geen reactie gekregen dus wordt vervolgd.

Verder heb ik mij bezig gehouden met een andere klant die ongeveer 60 servers bij ons heeft. Dit is dus een vrij grote klant ;). Het probleem was dat alle, ja dat lees je goed alle 60 servers het niet meer deden!! Na een kleine blik in het database server was het probleem al duidelijk. De klant had nog maar 30 mb vrije schijfruimte over. Hierdoor kon de database zijn records niet wegschrijven en ging de hele database over zijn nek. Na een verdere inspectie ben ik er achter gekomen dat er 2 databases zijn die samen ruim 70% van de gehele schijf in nemen. Dit is natuurlijk niet de bedoeling en dit hebben wij aangemerkt bij de klant. Vervolgens zagen wij dat 1 tabel in een database ruim 22GB groot was! Dit is een gigantische tabel dus! Toen wij deze tabel geïnspecteerd hadden werd al snel duidelijk dat per actie die er op de database gedaan wordt ongeveer 350.000 records geschreven werden in deze tabel. Waardoor de tabel ongeveer 230 miljoen records had. Ook dit hebben wij aan de klant doorgegeven. Het resultaat is nu dat de klant een harde schijf bij ons moet bijkopen. Dit zou zelfs kunnen leiden tot een nieuw hostings contract zodat zei hun eigen servers niet om zeep helpen.

Al met al een leerzame dag, tot morgen!

Dag 36: Dagje Servicedesk

Vandaag was het weer een normaal dagje op de servicedesk. Onze begeleider in de dagelijkse activiteiten gaat ons zoals eerder vermeld vanaf woensdag verlaten. Hierdoor is afgesproken dat deze geen actieve rol meer heeft in het bedrijf. Onze begeleider zal hoogstens kennis overdragen en helpen waar nodig. Doordat onze begeleider ons verlaat zullen Martijn en ik de rol van 1^ste lijn op de servicedesk gaan vervullen. Dit houdt in dat wij de problemen aannemen met de klant en dat wij communiceren met de klant wanneer het probleem is opgelost.

Dit hebben wij vandaag dan ook gedaan. Wij hebben vandaag allerlei problemen opgenomen en hiervan tickets ingeschoten op de helpdesk. Enkele van deze problemen hebben wij zelf kunnen oplossen. 1 probleem was bijvoorbeeld het laten uitvoeren van een .SQL script door een derde partij. Hiervoor moet er een request ingediend worden en deze kan tot 6 uur duren voordat die uitgevoerd wordt. Verder heb ik mij vandaag bezig gehouden met het contact met een klant die enkele problemen ondervond aan zijn VPN verbinding met 1 van zijn Oracle servers. Eerst is het probleem per telefoon geprobeerd op te lossen. Dit liep helaas op niets uit, omdat het probleem niet duidelijk geschetst kon worden door de telefoon. Hierdoor heb ik de klant gevraagd het probleem iets beter te beschrijven via de e-mail zodat wij intern konden gaan kijken voor een oplossing.

Verder heb ik de dagelijkse activiteiten van de servicedesk uitgevoerd zoals releases en deployments op development of acceptatie omgevingen zetten.

 Morgen ga ik weer verder!

Dag 35: Dagje vrij

Vandaag heb ik een dagje vrij gehad in verband het lang overwerken op een andere dag deze week. Hierbij heb ik als beloning een dagje vrij gekregen.

Dag 34: Een rustige dag

Vandaag was onze begeleider weer terug op de afdeling. Na enkele dagen van afwezigheid van onze begeleider. Dat onze begeleider weer aanwezig was, was te merken. De tickets de binnen kwamen op de helpdesk werden soepel verwerkt. Onze begeleider heeft ons waar nodig geassisteerd. 

Vandaag hebben wij verder enkele eenvoudige tickets afgehandeld zoals deployments. Verder heeft onze begeleider ons geholpen met het configureren van een FTP account in IIS. Dit moest gedaan worden door bij de huidige Default FTP Site een virtual directory toe te voegen en een gebruiker toe te voegen aan de server.

Verder heb ik mij vandaag gestort op het compleet maken van onze documentatie voor ons interne project. Deze heb ik dan ook compleet gekregen. Ik heb de volledige projectdocumentatie van circa 85 pagina’s nagekeken en verbeterd. Vervolgens heb ik het implementatieplan dat Martijn en ik geschreven hebben nagekeken en verbeterd. Nadat ik de documentatie compleet had, heb ik dit doorgegeven aan de operationele manager en onze begeleider voor goedkeuring. Wanneer wij deze goedkeuring ontvangen hebben kunnen wij doorgaan met het implementeren van het project in de interne omgeving van I-Company.

Morgen heb ik een dagje vrij gekregen omdat ik vorige maandag tot heel laat in de avond heb gewerkt om een website van een grote klant live te krijgen. Hierdoor krijg ik als beloning een dagje vrji.

Voor nu, lekker weekend.