De hele week? Even onder een stuk of vijf (non-administrative) domain-user accounts op het console inloggen en je kunt 90% van de mogelijke oorzaken al uitsluiten aan de hand van wat je tegenkomt.

Tjonge weer zo iemand die het beter weet.
Rob, dit zegt alleen iets over jouw onkunde.

Yep, weer zo'n knuppel die denkt op basis van een Computable artikel de problemen op te kunnen lossen voor een netwerk met ca. 26000 accounts, twee grote RC's honderden locaties en daarbij behorend netwerk.
 
En Rob voor jou oplossing is het resultaat simpel. 5 keer de melding: "You are not allowed to logon interactively"
Domain Users hebben normaliter niet de rechten om in te loggen op het console!:-)

lol @ marc!
 
Ach ja, net als in de andere topic hierover, je hebt altijd weer mensen met 0,0 verstand van zaken die zich er tegen aan bemoeien.

@marc, heb je het persbericht gelezen?

@Rob,
Yep, heb ik!

Hoe kun je nou 26000 accounts adequaat beheren en zo volslagen incompetent zijn? (zoals uit dat persbericht blijkt)

@Marc, You're not allowed to login interactively?? Sinds wanneer mag je dan wel onder RDP inloggen en niet onder console? Kun je me de policysettings even noemen?

Ik wil niet lullig zijn maar normaliter mogen domain USERS niet inloggen op een server hoor...dat behoor je toch echt wel af te sluiten. (OOK via console!).

Da's inderdaad lekker veilig, maar wel een beetje lastig op een terminal server. Ze kunnen dan namelijk niet werken.

I.v.m. de geheimhoudingsplicht hoeft niet alles wat de politie zegt ook waar en volledig te zijn. Waarom zou je buitenstaanders vertellen hoe je netwerk in elkaar zit.

In nov-2009 is 112-Meldkamer Oost-Nederland/Apeldoorn gekoppelt aan VTS-PN Oost-NL, begonnen met een Domain-Rename migratie, op de Top-Level van AD in de Single-Forrest, van 112-Meldkamer Oost-NL.
Ergens in Jan-2010 zou Meppel, Drachten en Zeewolde gaan volgen.
Misschien hebben ze door deze actie nu last van een Multi-Hommed-Domain, dat kan toch?
Als dat zo is, is er werk aan de winkel, op het gebied van Host-files bijwerken, DNS-A-Records omleiden en WINS uitschakelen, dacht ik zo...

Sorry allemaal, maar ik nu eenmaal DE GOEROE. Ik snap alles. Ik weet alles. Iedereen wil mij inhuren.

@Geen buitenstaander, als een server meerdere dns-registraties heeft, kan een client inderdaad een adres uit een ander segment krijgen. Als ie hem langs dat adres dan helemaal niet kan bereiken.....
Wellicht dat DNS voor loadbalancing bij de volgende request het aan ander adres geeft waardoor ie hem dan weer wel (even) bereikt.

@Rob
Jij bent echt DE GOEROE. Nu de handjes voor je gezicht weghalen en dan ... kiekeboe

http://www.eggheadcafe.com/software/aspnet/32056388/domain-controller-multipl.aspx

Ja, daar wordt je stil van hè.

1. Misschien kunnen ze beter gaan denken aan een ROLL-BACK naar hun oude systeem :-) Dat werkte tenminste wel goed. Ze zullen vast de oude hardware nog niet opgeruimd hebben?
 
2. Tenzij het helemaal niet meer de bedoeling is dat de politie gemakkelijk aangiftes kunnen invoeren.
Een INGEVOERDE aangifte betekend immers ook dat er IETS MEE GEDAAN MOET WORDEN en dat kost - den belastingbetaler - centjes. Deze systeemfailures zijn volgens mij gewoon een manier op kosten te besparen of het legale excuus te hebben van... sorry we hebben er niets aan gedaan want.... de computer was STUK :-(

@Rob, (ik was niet de 2e reactie) normaal gesproken heb jij gelijk, bij VTS-PN/Meldkamer ligt het allemaal ietsje ingewikkelder. 'Terug' een Roll-Back zo als 'RV' dit noemde, is hier niet zo zeer een optie.
(Ik zal inhoudelijk niet te veel op detail in gaan, want dat mag ik niet)
Wat bij VTS-PN/Meldkamer een directe optie zou zijn, is alle fysieke koppelingen tussen VTS-PN en de Meldkamer van Oost-NL tijdelijk uitschakelen, alle Clients via een remote command een 'seek' op DNS laten uitvoeren en remote alle opgebouwde ARP-Cache flushen - en dat kan en mag officieel niet, dat begrijpt iedereen, (vanwege openbare veiligheid) maar dat is wel de uitkomst om de priorities van alle verkeerd gebonden Clients in 1 keer te resetten.
Het probleem ligt hem in het feit dat er toch ergens onderin 'hidden connections' zijn, connections waarvan ze niet geregistreerd zijn, maar wel degelijk aanwezig.
Ik geloof dat ze bij VTS-PN even terug moeten schakelen naar 'The Basics of Networking', en AD even ongemoeid moeten laten, AD zit on Top Off, niet bij de bodem.
VTS-PN heeft geen verbindingen met 112-Meldkamer (zeggen ze), maar 112-Meldkamer is wel diegene die een 'Major Network Change' is ondergaan, juist in Oost Nederland, juist daar waar nu de problemen zijn, dat is echt geen toeval - ik geloof niet in toeval!

@1e Geen Buitenstaander. Ik kan me er niks bij voorstellen. Als alles weer goed staat, herstelt het vanzelf. Anders zeker na een herstart.
 
Ik overleg bij de eerste gelegenheid hier intern even en kom er op terug (als ik dan betere suggesties heb).

@1e Geen buitenstaander, ik heb even overlegd. arp-caching gaat alleen over je eigen ip-segment. Daar kan haast niets aan de hand zijn.
svp op de terminal servers even kijken met ipconfig /displaydns en zien of je ook gekke dingen tegenkomt.
 
wat bedoel je met een seek op dns uitvoeren? Hebben jullie static of dynamic routing? (niet dhcp)
 
Wellicht vanaf een rdp-client op intervallen pingen naar de TS en met Tracert kijken of verkeer consequent langs dezefde route gaat.
 
Het klinkt als een ip-conflict, dus misschien een server met snmp of syslog routers en switches laten monitoren. Als je korte haperingen op het netwerk hebt, eventueel het spanning-tree protocol (al of niet tijdelijk) uitschakelen. Wel uitkijken, want als je wel een misconfiguratie hebt, lig je dan helemaal plat.
 

@1e Geen buitenstaander. Ik weet niet wat voor dataverbindingen jullie hebben en van wie, maar wij hebben een keer gehad, dat de provider het aantal toegestane ethernetconnecties maar even omlaag had gebracht. Dus, terwijl je een vlan had, was je dus toch genoodzaakt er een router voor te zetten om je connecties terug te brengen. Ik weet natuurlijk niet of jullie switch to switch verbindingen hebben, maar je krijgt nergens een foutmelding als dat het probleem zou zijn.

Hahaha ongelofelijk dit.
3000 man, "super" it-ers werkzaam daar,waarvan 700 overbetaalde externen, en de zooi ligt er al een week uit.
Als ik dat flik, wordt ik er gewoon uitgetrapt!
 
Ik zou me echt kapot schamen als ik daar als IT-er zou werken!!!
 
http://www.telegraaf.nl/binnenland/5896668/___Miljarden_verspild_bij_politie___.html?p=11,2

@1e Geen buitenstaander: My two cents?
MS AD eruit gooien en overschakelen op een meer solide - Directory server voor data opslag
- Unix DNS deamon farm voor het netwerk gedeelte
Zou hou je je (netwerk_laag, data_laag) zaken echt vanaf rootlevel gescheiden en kun je des te efficienter storing zoeken in case is goes wrong (again).
 
Leuk hoor al die microsoft integratie, en als allemaal goed gaat (in een klein netwerkje) werkt het leuk.
Maar voor het echte, grotere werk kun je beter gaan leren vertrouwen op proven technologie op Unix platforms.
Deze tehcnologie was al jaaaren eerder uitgevonden, voordat ze bij microsoft de technology hebben proberen te integeren in "hun eigen" produkten
 
Good luck troubleshooting :-)

@Rob, aardig dat je wilt helpen - maar het technische probleem heeft hier een sociale, juridische en politieke kant.
Technisch was het al lang opgelost, ze hebben daar verschillende ip-segmenten - alleen politiek gezien ligt het allemaal veel gevoeliger - want dan hebben de sigmenten geen koppeling (zeggen ze), het gaat om meerdere partijen, en de management-staffs daarvan.
Daar kan ik me wel, maar wil ik me niet over uit laten, dus bedankt voor je info. Einde berichtgeving.

@1e Geen buitenstaander:
Dat klopt helaas wel. Wat naar buiten toe lijkt als EEN goed geolied en samenwerkende politie-apparaat.
Intern heerste een soort "primitieve stammenstrijd" en "domeintjes oorlog" tussen allerhande verschillende belangenclubjes, landelijk, vrs regionaale politie organen. Eigenlijk is het geheel intern zo gefragmenteerd als een ontplofte handgranaat of een gevallen spiegelglas
 
Het lijkt mij handiger als politietaken voortaan uitgevoerd gaan worden door het leger. Die zijn ten minste wel centraal georganiseerd ;-)

@RV: Bedrijven met tienduizenden medewerkers draaien op MS-AD. Die technologie heeft zich zo langzamerhand echt wel bewezen. Het politie netwerk in NL (zeker wanneer het maar een paar regio's betreft) is ook niet extreem groot en ook niet bijzonder complex of exotisch. De basis infrastructuur is niet noodzakelijk complexer dan van een middelgroot bedrijf. Als het dan zodanig mis gaat, kan de conclusie haast niet anders zijn dat er een schrijnend gebrek aan competentie heerst.
MS Bashing scoort natuurlijk altijd goed, maar lijkt me in dit geval niet gestaafd door feiten.

Lees dit stuk nu eerst eens, dst geeft een goed beeld van de complexe infra
 
http://www.minbzk.nl/aspx/download.aspx?file=%2Fcontents%2Fpages%2F96393%2F2008121602rapportv1-020102008technischonderzoekpolitiebasisvoorzieningenict.pdf

@IT'er:
Zoals je wellicht nog niet weet is dat Microsoft het "Active Directory Concept, idee, techniek, principe" niet ZELF heeft ontwikkeld, maar gewoon gejat, ge-reverse-eningeerd heeft van bedrijven zoals Banyan (Vines, StreetTalk.. een van de eerste echt directory services) en Novels eigen NDS en later E-Directory.
Ik weet dat dezelfde techneuten die eens Banyan StreetTalk (en rule based email filtering) hebben ontwikkeld en uitgedacht, tijdens de zgn. "Strategic Allience tussen Micrsoft en Banyan' (eind jaren 1990) nu verder werken bij Microsoft om het "MS-AD" concept stabieler te maken. Banyan heeft inmiddels opgehouden te bestaan.
 
Daarnaast zijn mijn argumenten geen "ms-bashing" zoals jij dat noemt, maar gewoon mijn eigen visie op it.
Volgens mij is het totaal niet handig als je alles aan elkaar vast probeert te knopen, zeer ondoorzichtig en verstikkend in elkaar verweven, zodat het op een monolitische structuur lijkt.
Central ICT Infrastructure Domination onder je "MSFT-AD-security" parapluutje.. zal altijd ergens struikelen als klanten gaan proberen te veel onder de AD paraplu te stoppen (uit onwetendheid on naturele groei).
 
Ik vind dat je vele malen beter af bent om alle componenten losjes - op puur noodzakelijke! basis - "light and lose" op een "need to know basis" te integreren, gelijk zelfstandige knooppunten in een grid of raster, of zenuwcellen in een neuraal zenuwnetwerk.
Dat geeft meer stabiliteit aan het gelijkwaardig samenwerkende (grotere) geheel, en het word heel duidelijk wie,wat,waar,hoe regelt. Weinig overhead en lekker snelle inter-system-communicatie mogelijk.
 
When the shit hit the fan (op welk level dan ook)...
Wanneer er dan een knooppunt of gedeelte van het grid faalt, heb je altijd de rest nog over om verder te kunnen werken.
 
Als er iets onder de complexe "MS-AD paraplu" faalt, dondert (bijna) alles meteen in elkaar omdat het zo lekker verstikkend aan elkaar geknopt is en intens met elkaar verweven.
 

Zie ook "Rule 3 van de Hacker Ethic"
"Mistrust authority—promote decentralization."
http://en.wikipedia.org/wiki/Hacker_ethic
 
Dit is heel handig om de stabiliteit en de onafhankelijkheid van verschillende deel-systemen in je ict infra-structuur te krijgen en te behouden. Daarnaast kan het o zo handig zijn bij het storingszoeken ;-) omdat je dan precies weet welk systeem wat doet en waar je dus moet zoeken als het effu niet werkt, zoals nu het geval bij de politie.
 
@Macro:
Je hebt idd gelijk een 36 paginas tellend pdf-rapport waarbij niemand erin geslaagd is (of aan gedacht heeft) om een PLAATJE toe te voegen van de infrastructuur..
 
Dat moet dan automatisch wel een heel complex systeem zijn :-)

@RV 11:22
 
'Volgens mij is het totaal niet handig als je alles aan elkaar vast probeert te knopen, zeer ondoorzichtig en verstikkend in elkaar verweven, zodat het op een monolitische structuur lijkt.'
 
Precies! en dat is ook wat er aan de hand is! Je krijgt een niet te managen systeem.
 
Deze architectuur is een afspiegeling van de organisatie. Die faalt ook!
 

Active Directory is toch Microsoft's implementatie van een X500 Directory Service? Het was de enig denkbare en jaren van tevoren aangekondigde doorontwikkeling van Windows-For-Workgroups/LanManager. Ze hebben het gebaseerd op de 97 versie van de ESE-engine toen Exchange zelf al op de 98 versie draaide. AD is veruit de meest bewezen directoryservice die ooit heeft bestaan. En dat heeft MS toch echt allemaal zelf ontwikkeld.
 
Als er met Active Directory wat aan de hand is, ligt de halve wereld plat. Overigens kom ik zelden een goed ingerichte Directory service tegen. Meestal is er wat doorgeborduurd op wat iemand ooit in een Novell Bindary heeft gefabriekt. Mede daarom hebben veel organisaties hun deployment ook zo slecht voor elkaar.
 
Aan het eindrapport is niet zoveel mis (zij het dat ik de 'evidence' voortdurend erg lichtvaardig vind vastgesteld). Maar er ontstaat wel een vermoeden dat er procedureel nogal wat aan schort bij de Politie-ICT. Legacy draai je niet de nek om, maar je biedt nieuwe functionaliteit en tegelijk integreer je dat in de backoffice met transactional services middels producten als Biztalk of de Message Queue Service. Zodra het kan, kondig je aan legacy niet langer te ondersteunen.
Verder lijkt er - direct vanaf de ontwerpfase - onvoldoende 'common ground' te worden gecreëerd voor ontwerpers/gebruikers/developers. Dat doe je door alle hogere/lagere ontwerplagen kort te sluiten dmv beginnen met een zo exact mogelijke gebruiks- en beheerdocumentatie. Als er dan toch nog hiaten/misverstanden in de communicatie zijn (denkbaar, want tussen mensen uit totaal verschillende werelden) is er een hogere kans dat het wordt gesignaleerd en - zo niet - zijn de gevolgen vaak minder groot.

Rob, ik denk dat relatief weinig Novell Bindery structuren in Active Directory zijn omgezet. Die zijn bijna altijd in Novell Directory Services overgezet (helaas vaak Quick-and-dirty met een migratie tool). De Bindery is van het Netware 2.x - 3.x tijdperk toen MS nog geen fatsoenlijke server kon maken, laat staan één die een netwerk kon managen met Directory Services.
Later zijn heel veel Novell Directory Services van Netware 4.x en hoger omgezet in Active Directories. En als je dan Quick-and-dirty migreert, dan krijg je een dirty Active Directory met wellicht ook nog eens foutjes uit een eerdere migratie naar NDS.
Je had trouwens hetzelfde probleem bij Quick-and-dirty migraties van MS Domain Services naar Active Directory.
 
Active Directory is intussen al lang een gedegen concurrent van NDS / eDirectory en andere Directory Services.

@frank.. Helaas geldt deze uitspraak niet alleen voor de politie maar voor (bijna) organisaties die hun chaos (uh organisatie) een-op-een hebben ge-eiland-automatiseerd zonder verder over de gevolgen na te kunnen, willen denken.
 
Op dat gebied is en zal er altijd nog een hoop werkgelegenheid blijven. Overheden, Organisaties en bedrijven GOED ict-en en automatiseren zodat "het digitale fundament" eeuwig bestand zal zijn tegen de economische, politieke en bedrijfskundige ger***** wat er bovenop wil rusten en er gebruik van wil maken.
 
Ik zie de marketingkreten alweer voorbij komen voor dit nieuwe revolutionary idee web 3.0 hype?
- "Organisatie-virtualisatie? (OV)"
- "Management resistant ict-foundation layers (MRIFL)"
- "Service Resistant Architecture (SRA)
 
@Rob:
"AD is veruit de meest bewezen directoryservice die ooit heeft bestaan"
Dat zie ik graag gestaafd met facts and figures uit neutrale bron.
 
"Als er met Active Directory wat aan de hand is, ligt de halve wereld plat"
Dat is ook precies een van de punten die ik wilde maken... Dit zou in mijn ogen technisch niet mogelijk moeten zijn. Hoe bedoel je vendor-lockin-threat.
 
"Overigens kom ik zelden een goed ingerichte Directory service tegen"
Dat komt ook om dat dit een aparte discipline is, het inrichten en opzetten van een goede directory. Das niet even iets wat je aan een gemiddelde netwerk,systeembeheerder uitbesteed op een weekendje of 2,3 overwerk. Daarvoor het je een enterprise wide wview and skills nodig.
 

@ICT-er, nu je dit zo zegt komen er allerlei herinneringen uit die tijd weer boven en - je hebt gelijk - ook bij onze klanten lag het genuanceerder. Er was vaak een soort co-existentie tussen 3.x en NT-4 en de migratie naar WinServer2000 was vaker van NT-4 dan vanaf Novell. Dat komt omdat wij weinig met NDS hebben gedaan door een traumatische ervaring met SFT-3 (en de ondersteuning daarvan bij Novell). De overgang van de NT-4 groepen naar O.U.'s in AD en de nieuwe rol van groepen daarin was het grotere probleem, vermoed ik achteraf.
 
Waar het mij om gaat, is dat je een hiërarchische structuur van pc's/servers in AD moet hebben op basis van geografie en gebruikersstructuur op basis van organisatiefuncties. De ultieme test is dan of er minimaal en maximaal één beheerdershandeling uitgevoerd moet worden als een pc of gebruiker een andere locatie of functie krijgt. Soms zie je een laag van gebruikerslocaties en daaronder weer een laag van functies in één hiërachie. Als je dan meerdere O.U.'s van dezelfde naam in verschillende parent-O.U.'s af moest, was het niet in mijn ogen optimaal ingericht. Dat was lastig als je gebruik maakte van assignen/publishen van toepassingen. Nou ja, mooie tijden. mvg

@RV, hoewel ik je de bronnen niet kan aanwijzen, ben ik ervan overtuigd dat ze bestaan. Het aantal installaties van AD - al of niet i.c.m. Exchange - is in de orde van een veelvoud van tien groter dan bij ieder vergelijkbaar product.
 
Service Resistant Architecture vind ik een goeie. Microsoft komt een eind maar juist dat bezorgt ze hun slechte naam: bij Linux/Unix functioneer je niet lang als je het zo slecht beheert als bij het gemiddelde MS-netwerk.