Overgaan naar Read-Only Domain Controllers

[YellowOnline]

(Nieuw plan)
Aktuele situatie: 32 DCs, 16 locaties in evenveel landen, 10 domeinen, 1 forest. Doel: één domein. Stap 1 is een RODC installeren op elke locatie die een deel is van het nieuwe domein. Nou ja, nieuwe domein: het is eigenlijk de huidige forest. We willen van alle parijs.yellowonline.com, brussel.yellowonline.com en amsterdam.yellowonline.com vanaf en gewoon nog yellowonline.com overhouden.

In mijn aanvankelijke startpost zat het anders in elkaar, maar dit is eigenlijk gemakkelijker: ik moet geen mogratie van FSMO-rollen doen aangezien deze RODCs naast de bestaande DCs komen tot ik de users gemigreerd heb.

Ik ben geen AD specialist maar ben plots wel verantwoordelijk voor dit project. Ervaring van andere mensen is altijd welkom

[ Voor 186% gewijzigd door YellowOnline op 26-05-2015 10:04 ]

[Semt-x]

Is er een groot risico dat de fysieke DC's op remote lokaties gestolen worden? zo nee, neem gewone DC's ipv RODC.

Waarom zijn er 10tal losse domeinen, klinkt als een ontwerp van 15 jaar oud (maar nu niet meer handig is). Het is veel werk om dat recht te trekken, maar ik zie bedrijven er toch voor kiezen. ze pakken de "pijn" nu, want hoe langer de wachten hoegroter de pijn. (er wordt steeds meer van afhankelijk)

[ Voor 4% gewijzigd door Semt-x op 26-05-2015 10:03 . Reden: typos, woorden enzo ]

[Jazzy]

Jammer dat dit topic weg gaat, ik zou het nieuwe plan ook wel willen horen. Dit zijn altijd leuke discussies. Kan ik je overhalen om het nieuwe plan gewoon te delen?

[YellowOnline]

Jazzy schreef op dinsdag 26 mei 2015 @ 09:55:
Jammer dat dit topic weg gaat, ik zou het nieuwe plan ook wel willen horen. Dit zijn altijd leuke discussies. Kan ik je overhalen om het nieuwe plan gewoon te delen?

Heb het anders verwoord nu. Kan wel mijn TR niet intrekken, dus het kan alsnog verdwijnen

Semt-x schreef op dinsdag 26 mei 2015 @ 09:53:
Is er een groot risico dat de fysieke DC's op remote lokaties gestolen worden? zo nee, neem gewone DC's ipv RODC.

De voornaamste reden is dat sommige van die locaties een werkelijk slechte uplink hebben (ik fluit de bits sneller per telefoon) en daardoor elke vermindering van de overhead helpt: er is een aardig verschil doordat er enkel inbound gerepliceerd wordt en niet outbound. Althans in theorie.

Waarom zijn er 10tal losse domeinen, klinkt als een ontwerp van 15 jaar oud (maar nu niet meer handig is). Het is veel werk om dat recht te trekken, maar ik zie bedrijven er toch voor kiezen. ze pakken de "pijn" nu, want hoe langer de wachten hoegroter de pijn. (er wordt steeds meer van afhankelijk)

Helemaal correct.

[ Voor 54% gewijzigd door YellowOnline op 26-05-2015 10:07 ]

[Jazzy]

Je zult inderdaad een lokale domain controller nodig hebben dus dat is een logische stap. Tenzij je het over honderduizenden gebruikers hebt is het cross-site replicatieverkeer van AD bijna verwaarloosbaar. Zie dit stokoude maar nog steeds heel bruikbare artikel: MSDN: Planning Active Directory for Branch Office Wel is het natuurlijk essentieel dat je site design klopt, maar op dat gebied verandert er eigenlijk niet zo veel voor jullie.

De echte uitdaging gaat zometeen zitten in het migreren van werkplekken, servers, (inlog) scripts, etc. Je kunt je trouwens afvragen of de uiteindelijke winst zich verhoudt met de hoeveelheid werk die 10 domeinmigraties met zich mee brengen. Ik bedoel, je zit al in één forest dus je hebt al SSO, centraal user en policy management, delegation of control, etc.

[F_J_K]

YellowOnline schreef op dinsdag 26 mei 2015 @ 10:04:
Heb het anders verwoord nu. Kan wel mijn TR niet intrekken, dus het kan alsnog verdwijnen

offtopic:
Ik heb de TR maar verwijderd. Topic kan zo wel door gaan, me dunkt. Ik houd me aanbevolen voor een geupdatete topictitel als je wilt, al lijkt dat ook niet nodig.

[ Voor 5% gewijzigd door F_J_K op 26-05-2015 10:31 ]

[DukeBox]

YellowOnline schreef op dinsdag 26 mei 2015 @ 10:04:
De voornaamste reden is dat sommige van die locaties een werkelijk slechte uplink hebben...

Houd er rekening mee dat dingen als DNS in AD nog steeds 2-way is. Heb je overigens al eens gekeken om hoeveel data het daad wekelijk gaat ? De meeste data (policies via dfs e.d.) is meestal vrij statisch en de wisselende data is vaak ook nog eens klein qua omvang. Als je beheer hoe dan ook vanaf 1 locatie doet (1 DC) dan heb je hoe dan ook weinig 2-weg verkeer.
Dingen als dhcp in dns registreren e.d. kan je ook allemaal lokaal beperken door met niet AD sub domeinen te (blijven) werken. Daarmee streep je het eerste punt al weg (al maakt het je dns forwarding e.d. wel complexer).

[Semt-x]

RODCs kiezen om netwerk verkeer te besparen levert meer ellende op dan je oplost.
Als er een slechte uplink is, is er deste meer reden om een volwaardige DC op die lokatie te hebben, zodat het inlog verkeer altijd lokaal kan worden afgehandeld, en niet op de RODC manier. daar maak je voor nieuwe accounts het inloggen afhankelijk van de uplink.

De hoeveelheid data die replicatie veroorzaakt is nihil. Dit heb ik gemeten toen ik moest kiezen om op schepen wel of geen DC te plaatsen.

@Jazzy, ik ben het met je eens dat het functioneel wel werkt, maar ben niet overtuigd of het op de langere termijn een gewenste situatie oplevert. Bijv. een ADFS implmentatie in 10 subdomeinen. en je daarna alsnog moet gaan migreren naar 1 domein, dat maakt zon migratie nog veel ingewikkelder.
Zo zijn er veel voorbeelden. Daarom ben ik voorstander om de "pijn" nu te pakken, dan het voortblijven modderen op een verouderde structuur, een bedrijf graaft zich steeds dieper in de afhankelijkheden, en elke migratie /implementatie wordt alsmaar ingewikkelder.

[Jazzy]

Semt-x schreef op dinsdag 26 mei 2015 @ 11:44:
@Jazzy, ik ben het met je eens dat het functioneel wel werkt, maar ben niet overtuigd of het op de langere termijn een gewenste situatie oplevert. Bijv. een ADFS implmentatie in 10 subdomeinen. en je daarna alsnog moet gaan migreren naar 1 domein, dat maakt zon migratie nog veel ingewikkelder.
Zo zijn er veel voorbeelden. Daarom ben ik voorstander om de "pijn" nu te pakken, dan het voortblijven modderen op een verouderde structuur, een bedrijf graaft zich steeds dieper in de afhankelijkheden, en elke migratie /implementatie wordt alsmaar ingewikkelder.

ADFS hoef je maar één keer te doen, want zelfde forest. Maar ik snap wat je bedoelt. Zo lang je maar goed in beeld hebt wat dit project jullie gaat kosten en dat afzet tegen de behalen winst. Zelf ben ik wat sceptisch, dat komt enerzijds door mijn ervaring met dit soort trajecten en anderzijds omdat ik niet helemaal helder heb wat de harde winst nu is die je hoopt te behalen.

[ Voor 8% gewijzigd door Jazzy op 26-05-2015 11:58 ]

[YellowOnline]

Jazzy schreef op dinsdag 26 mei 2015 @ 10:24:
Je zult inderdaad een lokale domain controller nodig hebben dus dat is een logische stap. Tenzij je het over honderduizenden gebruikers hebt is het cross-site replicatieverkeer van AD bijna verwaarloosbaar. Zie dit stokoude maar nog steeds heel bruikbare artikel: MSDN: Planning Active Directory for Branch Office Wel is het natuurlijk essentieel dat je site design klopt, maar op dat gebied verandert er eigenlijk niet zo veel voor jullie.

De echte uitdaging gaat zometeen zitten in het migreren van werkplekken, servers, (inlog) scripts, etc. Je kunt je trouwens afvragen of de uiteindelijke winst zich verhoudt met de hoeveelheid werk die 10 domeinmigraties met zich mee brengen. Ik bedoel, je zit al in één forest dus je hebt al SSO, centraal user en policy management, delegation of control, etc.

Helaas: user management, policy management e.d. zijn niet centraal. Dat is net een van de problemen: sommige users bestaan in verschillende domeinen met andere SIDs (afhankelijk van waar ze VPNen). Eigenlijk is er vrij weinig te doen op forest niveau. Voor mijn scripts die met user-attributes spelen moet ik elk domein apart queryen.

De reden voor dit alles is acquisitie. Bedrijf A koopt bedrijf B waarop de IT-systemen van A en B met elkaar moeten werken maar naast elkaar blijven bestaan. Enter bedrijf C dat bedrijven D en E opkoopt. Op een goeie dag besluiten A en C te mergen etc.

De vereenvoudiging qua domeinen staat buiten kijf: ik moet hier ook nog een resem producten zoals SCOM en SCCM implementeren (...mijn one-man show) en ook die producten worden een soepje in het huidige domein. Nou ja, het gaat wel (SCOM staat al op poten zelfs), maar het heeft geen zin om die ellende voor eeuwig te blijven meeslepen. Geef mij dan maar de korte pijn (zie ook Semt-x).

Semt-x schreef op dinsdag 26 mei 2015 @ 11:44:
RODCs kiezen om netwerk verkeer te besparen levert meer ellende op dan je oplost.
Als er een slechte uplink is, is er deste meer reden om een volwaardige DC op die lokatie te hebben, zodat het inlog verkeer altijd lokaal kan worden afgehandeld, en niet op de RODC manier. daar maak je voor nieuwe accounts het inloggen afhankelijk van de uplink.

De hoeveelheid data die replicatie veroorzaakt is nihil. Dit heb ik gemeten toen ik moest kiezen om op schepen wel of geen DC te plaatsen.

De meeste sites zijn redelijk klein (<100 man) dus dat er bij uplinkproblemen geen accounts kunnen aangemaakt worden is geen issue: er is daar zeer weinig personeelsverloop.

Overigens is het probleem niet de uplink down gaat maar gewoon ont-zet-tend-traag. We spreken dan over een theoretisch symmetrische 1MB of zo, snif.

[Jazzy]

Helder verhaal. Wat ik in de praktijk wel eens zie is dat een nieuw model wordt bedacht voor in het root-domein, dus bijvoorbeeld een OU structuur en delegation of control. Nieuwe acquisities kunnen dan direct naar het root domein, kleine child domains vervolgens ook naar het root domein migreren en de rest per domein afwegen. Maar goed, dat zou dan de uitkomst kunnen zijn. Als het voor jou haalbaar is om alle domeinen te migreren dan levert dat natuurlijk het mooiste eindresultaat op.

[Semt-x]

@Jazzy Ah ik zie welke aanname ik deed, ADFS slaat gegevens op in de domein partitie van AD niet de configuratie (forrest)partitie. Die data staat; CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=nl. vandaar mijn conclusie dat het een domein specifieke dienst was.

@Yellow, 1MB is meer dan zat. Op 1 van de schepen bij die klant was het destijds 128kbit. ( is nu 512kbit:) 128kbit is al meer dan genoeg voro AD replicatie met een domain van ~5000 gebruikers.
besparen van bandbreedte is RODC geen goede oplossing.
als een 1MB verbinding traag is, heeft het een andere oorzaak. om dat probleem deze keuze te laten beinvloeden vind ik niet handig, je graaft je mijn inziens verder in.

[DukeBox]

^ Idd (@2e deel hierboven).

YellowOnline schreef op dinsdag 26 mei 2015 @ 12:36:
De reden voor dit alles is acquisitie. Bedrijf A koopt bedrijf B waarop de IT-systemen van A en B met elkaar moeten werken maar naast elkaar blijven bestaan. Enter bedrijf C dat bedrijven D en E opkoopt. Op een goeie dag besluiten A en C te mergen etc.

Hmm.. zover ik weet heb ik hier geen collega's meer

Maar had hier 3 jaar geleden 8 (win 2003) DC's draaien en daar ging maar enkele MB's per dag overheen aan onderling replicatie verkeer. Bedrijf daarvoor hadden we er ruim 40 (+2 in one-way trust test omgeving) in 1 plat domein ook met 1Mbit lijntjes. Noot sync issues gehad en mailverkeer e.d. ging ook nog prima over die lijnen.

[ Voor 29% gewijzigd door DukeBox op 26-05-2015 13:06 ]

[YellowOnline]

Mja, ik heb hier proberen verkopen om toch bij R/W DCs te blijven, maar het is 5 vs. 1, inclusief de baas zelf Hun voornaamste argument is dat wat hun betreft de sites met RODCs mogen afbranden en dit geen impact op de replicatie zal hebben. Ze willen slechts 4 DCs op snelle en stabiele locaties overhouden waarom we ons bekommeren - de RODCs moeten slaafs volgen en mogen zelf niets richting de andere DCs sturen (het hele punt van een RODC, kortom).

Nu, tenzij ik mij vergis zie ik niet alleen weinig voordelen (behalve inzake fysische veiligheid) maar ook weinig nadelen om met RODCs te werken. In deze thread heb ik eigenlijk ook vooral "doe het niet" gelezen zonder veel praktische onderbouwing van de "waarom niet", behoudens het vanzelfsprekende dat men wel degelijk een aantal normale DCs nodig heeft om überhaupt met AD te kunnen werken

Het enige expliciete nadeel dat ik tot nu toe online vond is dat er wat exotische software is die niet met RODCs overweg zou kunnen.

[Jazzy]

RODC is niet bedoeld om op replicatieverkeer te besparen maar om je in te dekken tegen diefstal van een fysieke server. Laat ze het dan maar eens kwantificeren, reken uit welke bandbreedte ze gaan besparen. Dan zie je vanzelf dat dit een non-discussie is.

Dus de belangrijkste reden om het niet te doen is dat de reden om het wel te doen niet valide is. Persoonlijk heb ik vervolgens een beetje weerstand tegen zo'n papieren oplossing, je gaat het net een beetje anders doen dan gangbaar. Daar komt dan bij dat bepaalde applicaties (Exchange) een writable DC/GC nodig hebben en mogelijk ander applicaties die jullie ook gebruiken.

Maar zoals ik zei, als je samen vast stelt dat er geen reden is om het wel te doen dan hoef je ook geen redenen meer aan te dragen om het niet te doen.

[ Voor 51% gewijzigd door Jazzy op 26-05-2015 15:12 ]

[Semt-x]

Soms nemen ze adviezen alleen aan van externen. Ik zou het alsvolgt aanpakken;

1) uitleggen welke technische complexiteit RODC toevoegt. met introductie van RODC's er zijn meer problemen mogelijk die lastiger zijn te troubleshooten, omdat het veel minder word gebruikt en bedoeld is voor een ander scenario (fysieke diefstal).

2) deze extra technologie toevoegen als "oplossing" voor te volle data lijnen. Ik vermoed dat het niet duidelijk/onderzocht is wat voor data er over die volle lijnen gaat, ik zou inzage vragen in gebruik van die volle lijnen.

Als het besparen van data de belangrijkste reden is om een andere type DC introduceren in een omgeving, is dat een scheve beslissing. Voordat dat het besluit wordt genomen zou eerst in detail bekend moeten zijn waardoor die lijnen vol zitten.
Stel dat het inderdaad AD is, dan is het mogelijk een oplossing, als dat geen AD is moeten ze de andere bron(nen) aanpakken van het vele data.

Daarboven komt nog de vraag, hoeveel data wordt bespaard RWDC vs RODC. gezien ze allemaal het er mee eens zijn hebben ze dat blijkbaar uitgezocht. Ik zou inzage vragen in dat onderzoek.
sterk afhankelijk van de grootte van het domein en gebruik ervan, zal het verschil, absoluut gezien, nihil zijn. kilobytes per minuut is al veel.

Om een idee te geven bespaart RODC niet alleen het verkeer door alleen relevante objecten te synchroniseren, maar RODC levert ook extra verkeer over de lijn;
- Dynamic DNS updates voor een AD integrated; centraal gecomprimeerde replicatie tegenover alle clients die direct zelf naar een RWDC hun record updates (RODC doet geen DNS dynamic updates).
- Hetzelfde geld voor de computer-account wachtwoorden, die elke 30 dagen automatisch worden gereset, met een RODC gaat dat over de lijn, met een RWDC wordt dat lokaal afgehandeld, en wordt door site replicatie de data verzameld en gecomprimeerd naar HQ verstuurd.
- LastlogonTimestamp bijv elke keer als iemand inlogt is nog zon veld. zo zijn er nog meer.

Tot slot, in de afgelopen ~10 jaar dat ik AD werk doe, heb ik een tool geschreven die het huidige gebruik van AD in kaart brengt. Alle details die nodig zijn om AD domeinen te ontvlechten en te versimpelen kan ik in 10 minuten opleveren. De gegevens die ik daarmee verzamel vormen nog een tegen argument om meer complexiteit in te voeren in de vorm van RODCs.

[Widow]

YellowOnline schreef op dinsdag 26 mei 2015 @ 09:35:
Ik ben geen AD specialist maar ben plots wel verantwoordelijk voor dit project. Ervaring van andere mensen is altijd welkom

Ik wil best helpen met meedenken, maar ik mis een beetje een totaalplaatje wat je wilt maken, of waar het aan moet voldoen kan je wat meer details posten? Bijvoorbeeld een overzicht van de fysieke structuur, met de locaties, bandbreedte en dergelijke, en de logische structuur, zoals waar welk domein/forest leeft, waar de FSMO rollen en global catalogs staan, hoe intra/intersite replicatie geregeld is, forest/domain functional level en dergelijke.. dan hebben we wat concreets om over mee te praten

Trouwens, als je niet heel veel van AD weet, dit is een aardig artikel dat e.e.a. uitlegt:

https://technet.microsoft...255&MSPPError=-2147217396

Ik heb trouwens bij een paar klanten op locaties met RODC's gewerkt, en ik moet eerlijk zeggen dat er weinig van te merken is. Als je goed gaat zoeken zie je bijvoorbeeld dat er bepaalde service records in DNS alleen verwijzen naar de schrijfbare domain controllers. Echter, het gedeelte over dat het bandbreedte bespaart, of dat bij diefstal de replicatie niet in de war loopt, zijn niet de argumenten waarom ze destijds geplaatst werden. Het is echt bedoelt voor fysiek minder veilige locaties. Misschien bespaar je wat replicatie bandbreedte, maar bedenk dat er ook acties zijn waarbij een schrijfbare domain controller nodig is, wat weer bandbreedte kost. En als een RODC word gejat moet je nog steeds in je AD acties uitvoeren om te zorgen dat deze op een nette manier verwijderd word

[Razwer]

^ dus dat.
De beredenering van RODC's is totaal verkeerd en ook zekers niet goed toegepast. RODC verhoogd alleen maar de traffic over de sites en is bij slechte lijn verbindingen alleen maar storend voor de users.
Beter los je het op met gewone DC's en jouw AD replication juist op te zetten, desnoods alleen manueel in een hub-spoke oplossing.
Jouw plan doorzetten ga je van de regen in de drup.

Edit: voordat ik iets kan neerkalken alweer 2 reacties er op

[ Voor 7% gewijzigd door Razwer op 26-05-2015 16:21 ]

[YellowOnline]

Eerst en vooral: dank u voor de reacties tot nu toe.

Razwer schreef op dinsdag 26 mei 2015 @ 16:20:
[...]Jouw plan doorzetten ga je van de regen in de drup.[...]

Niet mijn plan!

Wat achtergrondinformatie: ik werk hier 2 weken en ben aangeworven als System Center specialist / Powershell scripter, maar ben blijkbaar gepromoveerd tot Microsoft-specialist aangezien ik naast SCOM, SCCM en SCSM opzetten ook nog Skype For Business (de oude Lync) opzet en de migratie van 32 DCs op mijn dak krijg... na anderhalf jaar uit roulatie te zijn wegen stress. Iets zegt me dat ik weer niet lekker bezig ben en eens "neen" moet beginnen zeggen

Enfin, de omgeving: op 2 2008R2s na zijn alle DCs 2003 of 2008. Er staan er drie op bepaalde plekken in Europa die de forest bedienen en de rollen zijn min of meer verdeeld over de drie (GC, PDC, RIM, ... weet niet uit mijn hoofd wie wat) maar daar is niet veel gaande. De users leven in een domein gebaseerd op locatie. Elk van die domeinen heeft 3 DCs, waarvan er 1 op een andere geografische locatie staat (redundantie-idee).

Het idee is om een stuk of 4 DCs in de grote sites te zetten en RDCs in de kleine sites, alles 2008R2 in het Engels (want nu zijn server installs in alle mogelijke Europese talen). Dit om user management te vereenvoudigen en wat te doen aan AD problemen allerhande - vooral mbt. replicatie. Ik ben er nog niet lang genoeg om daar een goed idee van te hebben, maar in SCOM zie ik wel elke dag verschillende errors passeren dan een server de FSMO rollen niet kan vaststellen of dat een PDC niet gevonden kan worden.

Alles blijft draaien, maar optimaal is het niet - laat staan eenvoudig te beheren. Ik ben absoluut voorstander van de vereenvoudiging die gepland is. Maar van wat ik hier en elders op het internet lees ben ik niet overtuigd van hun idee RODCs te gebruiken ipv "R/W" RDCs. Geen idee hoe ik hen dat morgen nogmaals aan het verstand kan brengen, aangezien ik niet echt de autoriteit ben in AD tout court en bij uitbreiding ook de vreemde eend in de bijt ben (niet alleen als nieuweling maar ook als enige niet-Duitser )

Ik moet trouwens nog een snelcursus ADMT volgen, want users migreren wordt vast het leukste gedeelte. Vooral met hun toegangen tot Oracle en een hele NetApp backend.

Op zich zie ik het wel zitten.

[Jazzy]

Je bent geen Duitser, komt er net bij en bent niet zwaar genoeg op de materie om als expert geaccepteerd te worden. Volgens mij moet je overwegen of je deze strijd aan wilt gaan. En als ik zie wat er verder voor projecten aankomen, inclusief 10 domeinmigraties, zou ik me inderdaad wel een beetje zorgen maken over je nieuwe rol en werkdruk.

Nog even een kleinigheidje, Server 2008 R2 is opgevolgd door Server 2012, Server 2012 R2 en later dit jaar Server 2016.

[ Voor 26% gewijzigd door Jazzy op 26-05-2015 20:46 ]

[YellowOnline]

Jazzy schreef op dinsdag 26 mei 2015 @ 20:46:
Je bent geen Duitser, komt er net bij en bent niet zwaar genoeg op de materie om als expert geaccepteerd te worden. Volgens mij moet je overwegen of je deze strijd aan wilt gaan. En als ik zie wat er verder voor projecten aankomen, inclusief 10 domeinmigraties, zou ik me inderdaad wel een beetje zorgen maken over je nieuwe rol en werkdruk.

Nog even een kleinigheidje, Server 2008 R2 is opgevolgd door Server 2012, Server 2012 R2 en later dit jaar Server 2016.

Ik kan enkel de licenties gebruiken die deze klant ter beschikking stelt. Zolang ze nog voldoende 2008R2 licenties hebben moet ik die gebruiken. Nieuwe locaties met nieuwe DCs krijgen waarschijnlijk wel 2012R2 of 2016.

En voor de persoonlijke noot: mja, ik moet weer leren met werkdruk omgaan.

[Alex)]

Een nieuwe AD-deployment en dan wordt er gekozen voor Windows Server 2008 R2, een product dat al een paar maanden in extended support zit?

Om eerlijk te zijn klinkt me dat niet als een erg toekomstvaste oplossing in de oren (je moet binnenkort dus upgraden), beter trek je nu wat extra geld uit en dan zit je de komende jaren goed.

[Jazzy]

YellowOnline schreef op dinsdag 26 mei 2015 @ 21:21:
Ik kan enkel de licenties gebruiken die deze klant ter beschikking stelt. Zolang ze nog voldoende 2008R2 licenties hebben moet ik die gebruiken. Nieuwe locaties met nieuwe DCs krijgen waarschijnlijk wel 2012R2 of 2016.

Ik snap dat jij moet roeien met de riemen die je hebt. Maar je gaat nu dus nieuwe servers uitrollen met een OS dat al in Extended Support is en later dit jaar drie generaties achter loopt.

[Razwer]

Mocht je op de werkvloer op verweer stuitten verwijs de architect danwel schrijver van het T.O. op vriendelijke wijze naar dit topic.
Er zijn genoeg AD zwaar gewichten hier die (gratis) juist advies geven. Diezelfde zwaar gewichten zijn ook in te huren voor een niet misselijk tarief
Met "zwaargewichten" doel ik overigens niet specifiek op mijzelf. En waar is Mark als je hem nodig hebt

[ Voor 17% gewijzigd door Razwer op 26-05-2015 23:08 ]