darkstar

Got it Two problems The default page was an asp file which queried another server running SQL (Sims actually) in another forest all together. In the ODBC control panel there were a host of homegrown connections - the main one still pointed to the old ip address. Funny - how this could bring down the whole lot. The virtual folders were down due to a small setting in virtual directory properties/application settings. The second issue was down to our good friend DNS. I needed to put in a A record to http://WWW.jrs.local phew

No - localhost does not work although logging is OK at its default location. We rebooted a couple of times but tna. We have tried with both unassigned and ip address in site properties but unless we can see the virtual directories including all the exchange stuff then I can't see it coming up. I tested the procedure on a test rig at home and all was well so its difficult to see where we have gone wrong. We tried to create a new web site and put a test html doc in there and we seem to be able to get that by typing http://10.100.0.4 but not when we type http://jrs.local - resolution? I wonder if their are two problems here? If I try and ping JRS.Local (our domain) I get a workstations ip back. If I go nslookup jrs.local I get a list of IP's, four of which are our new 10.0.0.0 range (including servers) and about 30 in the old 128.0.0.0 range. Surely this is wrong. Whats the deal with reinstalling IIS - would you normally expect to lost all of the settings. If you hadn't already guessed - I'm a complete numpty when it comes to IIS.

Hello We are having problems with IIS since we changed the IP address range. The ip address change on a whole went quite well and it seems that DNS (where we expected problems) is actually fine. Nevertheless, looking in IIS it looks like we have lost all the virtual directories. IIS does not seem to work at all and surprisingly there are no useful events being logged. There are of course the IIS log which have entries like 2006-04-04 06:40:29 10.100.0.119 - 10.100.0.6 80 PROPFIND /libraryresources - 404 Microsoft-WebDAV-MiniRedir/5.1.2600. Does this indicate that requests are arriving correctly? Is there anywhere in IIS where the ip binding would need to be set that I might have missed?

Hi guys OK - we managed to get a 'real' IP scheme given to us by Kingston. 10.100.0.0 I did the change over yesterday and did as you suggested and created a reverse lookup. All is well with the exception of IIS which appears to have lost its virtual directories and will not not work. Unfortunately this server seems to have corrupt event logs - not the most useful thing when trying to diagnose problems. I guess I'll have to try the Microsoft fixes to try and get the events back up. I was wondering if anyone had heard of problems with IIS after IP changes. I did find one obscure post somewhere but that was NT4. I wonder if I should contact the admin at CMU, after all, we did seem to be a part of the university campus at one point LOL ;-)

Ok - its all coming out now. The head of ICT now remembers that the council had set us up with 192.168. blah. Apparently the school ran out of IP addresses so a guy came in from another school and set the school up with a class B - only instead of 172 he assigned 128 telling all who cared to listen that we were natted so it would be OK. And it was OK for two years. I tried to log on to one of our Access Points yesterday and was presented with the portal for the Carnegie Mellon VPN. - highly amusing So it looks like we'll be able to nail this one now. I can't believe everyone has missed the absolutely blindingly obvious. I think its something like - how can anyone make such an elementary, basic error? Sometimes I suppose it just needs an outsider to point these things out. Thanks

Yeah I know it's not strictly correct because it should be in the private range but we are behind that many layers of NAT. The internet is provided by the York council/Kingston/Affinity and they set this network up here long time before I got here. Other schools in this area also use 128.0.0.0. As far as the internet is concerned our machines are seen to have one single class C address which is one of Kingstons machines. .... so, could this point to a configuration issue within our providers systems?

mmmmmm Our range is private

OK – we’ve got something similar but with the addition of a number of gruel entries. The reason I mentioned DDNS was because ALL records in the cache are ordinary A or NS entries with the exception of those pertaining to CMU. Nevertheless, if it’s normal to have ddns in a cache then all well and good. However, in our cache there are reverse lookups and the only PTR records in the cache are the Gruel ones which can number a good 80 or so. I can’t see this as being normal. If I do nbtstat – a, for example 128.2.2.9 I get the correct netbios name ‘FTT10’. If I ping the same machine with the a switch I get GRUEL-2-9.PPP.andrew.cmu.edu. This is despite their being a legitimate A record for the machine in the forward lookup. Nslookup 128.2.2.9 returns GRUEL-2-9.PPP.andrew.cmu.edu. I am wondering what is the significance of all gruel entries being ptr records? Our network runs on 128.2.1.0 (16) and the corresponding gruel address will always have the host part of our network (I origionaly posted ‘network’ - sorry about that) e.g. 128.2.2.9 will become gruel – 2-9 ……….. It was ethereal which first alerted us to this problem and all our monitoring stuff says the same (we use network supervisor from 3com and we’ve just acquired observer after running a load of trials). I’ve changed all passwords as you’ve suggested and I continually monitor event logs. I’m going to have a deeper look at anti-rootkit tools. Your suggestion running ethereal inbetween the network and the gateway sounds like a good idea.

Actually, I've been running this past the head of ICT and I think we're gonna flatten everything. This will have to wait till the summer though.

mmmmmmm It's the verify no malware which I'm finding a bit tricky. I've run all sorts of stuff - nmap to see whats listening, rootkit revealer etc and they all come up clean. nevertheless, this does not mean to say that it is in fact clean. Not sure exactly what you mean about the mappings. The cache appears to look normal in my limited experience with exception of these rogue GRUEL entries and whats with the DDNS in the cache? I could mail details over to someone if they are willing to have a quick look for me and see what they think? Unless I can actually nail this one and say with a degree of certainty that I know whats going on -then as you guys have said - I can't trust it.

yeah When I started here in the summer the staff used laptops with full admin rights and blank passwords to boot. The amount of malware that came in once term started had to be seen to be believed. I put a stop to that by reimaging all laptops and locked them down. Some staff still won't talk to me accusing me of being paranoid. This job really is between a rock and a hard place. Just for info, when the virus first kicked off I advised just what Grumbledook suggested but the head overruled me. Then by christmas the network was working fine as far as performance was concerned. It's only recently that server behaviour indicates that its been compromised big time. I think I'm gonna have to bite the bullet. Anyone fancy a busmans holiday in York LOL ;-)

We have about 400 or so winXP machines running on w2k servers. Back in September of last year we were hit with the SDbot virus which infected all the clients. In addition we discovered a root kit on some of the workstations. We managed to get the network clean with the exception of the following strange behaviour. Doing some routine scans we discovered that some of the clients were reporting their DNS names as variations of the following GRUEL-2-142.PPP.andrew.cmu.edu The -2-142 would be the network part of our ipaddress and the rest resolved to The Carnegie Mellon University in Pittsburg USA. Looking in DNS we could see that these addresses were in the DNS cache which we cleared (on the server that is). This brought temporary relief but the Gruel addresses soon returned even on clients that were re-imaged leading us to believe that the problem related to DNS itself. Some form of poisoning ??? Despite this worrying trend the network was working OK and I’d attempt to do some research into this whenever I got a spare minute. However, things began to change about two weeks ago. ActiveD showed some strange behaviour. The DHCP scope disappeared without trace one day followed by all the forwarders having been taken out of DNS on another day. We have some additional machines in the DNS cache now which are in the same EDU.CMU.ANDREW. tree and say they are DDNS. There are A records which call themselves things like ddns-master with an IP in our range. And NS servers called things like ddns-a100.net.cmu.edu. Most worrying of all the server decided to stop playing today and no one could connect to network shares and hence were unable to login. The server ground to a halt and it needed a reboot to get things going again. There does not seem to be anything in the event logs worth mentioning. Hardware is OK - I'm thinking something overwhelmed SMB. Any ideas on how I can clean DNS or even to try and get a better understanding of what is actually going on.

I'm the cautious type only too aware how those CLM can leap out at one. However, I've actually found an old server that I may be able to press into use and set up as a lab, now I think I may be straying into another topic and there might be a thread somewhere hereabouts, but when you guys test do you DCPROMO a test DC into the production environment and then disconnect it? I'd really like to replicate as much as I can so that I can test anti-virus, patches etc but I understand I'd probaly have to run ntdsutil to clean up the metadata on the production AD. Is this hazardous - it looks pretty straightforward - but these as we are only too well aware are the quintessential famous last words. If you are interested in a snapshot of your current AD, you can: - dcpromo a new DC in production - make the new DC a GC - install DNS on the new DC - disconnect the new DC from production network - clean up the DC's metadata in production environment - put the disconnected DC in a seperate VLAN - seize the FSMO roles - in the test environment perform metadata cleanup to remove the production DCs from test environment. - update the sites&subnets info to reflect the new test subnet layout

How on earth do you get the time to test updates LOL. Actually, it sounds like its just a case of common sense. Anyway - cheers for that

I'm the new techie and this is my first time working at a school. Unfortunately I have inherited an unstable network with extremely precarious servers - no documentation and no handover, security is noticable by its complete and utter absence - no patch management - antivirus 13 months out of date and only installed on a small handfull of clients, etc etc. phewwww. Running hfnetchk on the servers revealed that many patches are missing. My query is - what is the best policy on patching servers. We can't test anything - and servers typically are multirole machines (SQL, Exchange and whatnot). I'd like to deploy WSUS across the network but as far as the servers are concerned it's not unheard of for patches to break exchange or SQL. The last place I worked everything was tested, but this really isn't viable in a school is it?