azrael78

On your knackered ISA box, check the Service dependencies in regards to the firewall service. Then check each of these services to ensure they are started. I did a quick look around the Net but error code 2 (0x2) isn't one that I came up with. A few similar things in regards to the EventID came up and they suggested checking other services, as the ISA firewall service may be failing due to one of it's dependencies failing on you. HTH, Az

+1 - I can do more than mirror this comment. We use Acronis extensively in our school, works great for SQL, AD... you name it. Plus if you purchase the 'Universal Restore' option - you can perform bare-metal restores of hardware or even restore backups onto dissimilar hardware. Az

Certainly sounds peculiar. So, if you log that laptop in as staff - it's fine. If you log it in as any student - it's not? Next time you get a chance, clear the event logs - reboot the laptop (while connected to the network) and then login as a student, see if anything pops up in event viewer. Is the laptop wireless by any chance? Does it do the same if you have it wired in or wireless? As for more time with the laptop - try this: (This assumes you have some kind of Virtual PC type software available) 1) Take kids laptop - clone it using whatever software you use, don't sysprep it. (I say don't sysprep, simply due to time needed to rejoin etc... particularly if the kid uses it every other lesson...) 2) Create a new VM - same OS, RAM etc as the laptop you cloned. 3) Restore the clone into the VM (but disconnect the network from the VM). 4) Login locally to the VM (keep it off the network) 5) Take the VM off the network (disjoin from domain) 6) Reboot and rename PC to something else different 7) Reboot and run newsid to generate a new SID 8) Reboot once more, connect to network and rejoin domain Hopefully this should give you a 'test' box you can play with (back it up before you start) so you can isolate the cause without having to rely on the laptop itself. This may not help you at all - but even if it doesn't, hopefully someone may find this idea useful. HTH, Az

Another thing that may be possible is that your drive may be 'mis-reporting' - did you check the drive on the server itself? In any case, suggest you run a checkdisk/scandisk on it when you get the chance just as a 'belt and braces' approach. As for checking quotas... if you are Server 2003 R2, you need to use the File Services Management snap-in (I believe there is a seperate one in Administrative Tools for Quotas). In any case, once you find the snap-in (or just use MMC and add the quota snap-in yourself) - the first part of the tree should be quotas, second part should be file screens and the third should be reporting. Expand the first part and let it list the quotas you have. I don't have a Server 2003 R2 within reach (either remote or local) or I'd be able to give you exact instructions. This article may help HTH, Az

I'm not sure on this - I get the feeling that it takes up however much space is required - meaning that it takes 'snapshots', so if say one of your drives on day 1 has 100GB used, and on day 2 it has 110GB, then I *think* the snapshot is 10GB. It may have compression in there somewhere too but I'm not sure. As for moving shadow-copies to another drive/NAS, I don't know if this is possible - I don't think it is, but IF it is - then I'd start using Shadow Copies myself. I hope this helps... even if it's a little bit Peace. Az Edit: Didn't see SYNACK's post... ignore mine then

Not sure - we did the 'disable run' GP bit but when we did Windows + R - it let them still run stuff, so we've taken the route of disabling the windows key itself. Peace. Az

I'm not familiar with busibox at all - but I'm reasonably familiar with ISA. It sounds like you want to use ISA as a kind of gateway which is what we have here. Here's one way you could implement what you want: 1) Configure the busibox IP so it's a seperate range (say 192.168.200.x/255.255.0.0). 2) Create the ISA server with 2 NICs, 1 connecting to your internal network and 1 which is on the same IP range as the busibox. 3) Configure ISA to allow web-proxy requests on port 80 for the Internal network. 4) Setup the ISA firewall rules so that ISA talks directly to the busibox. Now this won't necessarily stop people accessing the internet if SurfControl dies, but it will mean that no internet traffic (except from what you configure on the busibox) will ever get to your busibox except from the ISA server unless you specify otherwise. Is there an error message when your surfcontrol just dies? It might be worth looking into why your SC dies as well, so that you have a robust internet proxy/monitor box and your busibox is secure also. Hope this helps or sheds some light. Az

My personal choice here is to give them Modify permissions, rather than FC. Simply because it stops them changing or granting permissions to other users (even if they can't see the security tab, they can still use CACLS... and I'm paranoid ) Az

This in itself is worrying - it should not be trying to write here, very few things should. Login as someone you CAN'T run it as - fire up filemon/regmon/procmon, let it start monitoring - then fire up adobe, get to the error bit, make a note of the time (to the second if possible) - close down adobe, then stop the monitoring. Could you then save this (leaving it all intact) somewhere so we can take a look? The information you provided didn't yield anything immediately but it may not be complete. You want to monitor both registry and file access/writes (which if I recall, is default behaviour) - just incase, use filemon and regmon seperately. So do 1 run as described with filemon, save it. Repeat with regmon. This gives 2 files that means it's easy to pick through seperate file/registry issues - might also help with tracking it down faster Az

At a wild guess I'd say the /cd means - 'connect' + 'set default', so it sets \\s1\h114 as the default printer, whereas the /c is simply 'connect'. Az

It's also possible that when you run the command, sysprep (or a process within) is resetting the drive letters. Perhaps an easier way would be to stick it in RunOnce for All Users, means sysprep shouldn't run it and it should run AFTER sysprep completes. However it's also possible that diskpart may not have permission to do what you are asking, which it may well not do with my suggestion above. It's tricky - had a similar situation where a cloning disaster caused drive C: to appear as D: and A: to appear as C: - oh yes, that was fun. Alot of digging for certain registry keys solved it. Let me see if I still have it... Okay... on a PC that works as expected. Under HKLM\System\MountedDevices is a bunch of keys with volume GUIDs in them. There are also ones called DosDevices. Export that registry key and use a text editor to compare - much easier. Open up the registry file in notepad. The values for DosDevices should match the Volume{GUID} - so in your case, look for the following: \DosDevices\K: Look at the value data for this and find the same one in the \??\Volume{GUID} bit. Using notepad search, you can quickly find the one you want - now you want to copy the bits of the keys you want (the single Volume{GUID} and DosDevices entries that match) into a seperate .REG file (make sure you keep the first 2 lines of the original export file). Import this on a PC that didn't have the right letter and reboot. Hopefully - albeit a long-winded way, but it should help. Az

Create a new student account, assign it all the usual policies except give it the ability for 'Start -> Run' and give it the command prompt and registry editor. Run the program - it should fail just as before. Download FileMon and RegMon Using RUNAS - run FileMon as a local admin, clear the log of filemon and stop the logging. Start Filemon logging - run the App. When it fails, stop Filemon. Apply a filter that has the word 'DENIED' in it. Do the same with Regmon. These will hopefully point out what the app is trying to do, where it's trying to do it and why it's failing. It's a tricky process to get right but it does mean you can find a fix for it (hopefully) and patch it on the PCs that need it now and in the future. Az

I don't know about 2008 (as I've not had a proper play yet) but in 2003 GPO you have options to force classic start menu, you can also hide the 'all users' stuff via GPO too. As for the double clicking, we got rid of that here but I can't tell you how because to be honest - I can't recall. However I'm now keen to upgrade to 2008 just to see if our setup will hold or whether it will be a huge job to re-jig it. Az

The only issue I can see with using a DB of any kind is ghost sessions, where the kids don't bother to logoff but simply shut the PC down. You might want to add some way to easily clear a session from the database if you are going to do it that way - as for me, I'm looking at a bunch of text files that can easily be deleted if we have issues or can easily free up sessions based on PC identity rather than user identity - but this is all ideas in my head and I need manglement approval to implement something like this. Az

This might be a long shot - but double check your NIC drivers. If these are a bit flakey then they could cause issues. But it is a long shot, we've had issues here with drive mappings, printers and such and it boiled down to a select few PCs with old NIC drivers. Updated them and the problem went away. Az

Okay, it's sorted. It turns out the stupid machine was just taking an age to re-read the policy from the DC, despite the fact it's been left alone and nothing has been stressed out. No errors in the eventlog - no nothing. But explain something - for those of you who use 'deny all but' rules - the designated filetypes - these are blocked or permitted? In my 'allow all but' rule, the filetypes are blocked unless I've made a huge mistake somewhere. Az

I understand what you mean perfectly and you are absolutely right, however I don't feel confident enough to hit 'deny all' and then permit little bits, I'd rather do it this way until I'm comfortable with how SRP works exactly. I'm the only one in a team of 4 who has any idea about AD and how it works, so I like to take things slowly when I'm unfamiliar with something like this. I'd rather allow too much and have to lock down, than lock down too much at this stage - but I will take your suggestion onboard and will be looking at SRP (assuming it works well this time around) and will be working on the premise of 'deny all but' rather than 'allow all but' Got all that on my admin workstation - what I found is that an XP SP2 PC that has never seen SRP before updates just fine from the AD and is okay - but one that has seen it needs ALOT of reboots and to my way of thinking that's stupid. But I just tested my SRP setup on a new VM and it works fine - as no other PCs on site (except my original testing PC) have seen SRP, I'm hoping this will all work out. I'm using *.MDB and then blocking B:\. It gives me the desired result I wanted Az

I've just tried that one ZH - unfortunately the PC on which I'm trying this REALLY HATES SRP for some reason, if I update the policy, I have to disable the link, reboot the PC, enable the link and then reboot it to make it work. It's driving me crazy (well, crazier) Az

Michael, I want to stop the kids running undesirable file types from USB sticks. Hence why I've got B:\ as a denied path (that's the drive letter for USB sticks). But I still want to allow them to open office documents from B:\. What I don't understand is why it's denying MDB files - when it shouldn't be. They need to be able to 'see' B: drive and read/write to it but I don't want them running things from it. Az

Morning all, I've been tasked with getting SRP working properly. I've taken the 'blacklist/deny' approach (where everything is permitted EXCEPT what we deny). I'm sure that doing it the other way (where everything is denied...) is just as good but I can count on my fingers what we don't want the kids to get at. So... I have several path rules setup - some set to deny and some set to permit. Now here's an example... B:\ - Deny (USB Drive Letter) Now I can open all office docs here EXCEPT MSAccess MDB Files by double-clicking. On the MDB files it says it's blocked, however MDB does not appear in the 'designated file types' list and even if I put it there, it makes no difference. So... B:\*.mdb - Permit This works provided the MDB is in the root folder, it doesn't work if that MDB is anywhere else on B:. So am I doing something stupidly wrong with this or am I missing something obvious? I will post the full configuration in a bit, gotta do a bit of early-morning fire-fighting first but any suggestions in the mean time would be great Az

I find this a little odd - not that I'm saying you are wrong at all Michael. On our system, we have a single global profile - all students share this - permissions are as follows: Share - Everyone:READ, Admins:FULL, SYSTEM:FULL NTFS - Everyone:READ, Admins:FULL, SYSTEM:FULL The profile is tiny and it never seems to complain about lack of rights or anything when trying to write back the mandatory profile - I was under the impression that a mandatory got downloaded to the workstation, used and then simply discarded - no write-back to server as it's mandatory and therefore, shouldn't be changed. I could be wrong though Az

It's worth noting that with DLL registration you IDEALLY want to copy the DLL from a central point first (NETLOGON share) and THEN register it. So something like the following: Copy %LOGONSERVER%\NETLOGON\MyDLL.DLL %WINDIR%\System32 /Y %WINDIR%\system32\regsvr32.exe /s %WINDIR%\system32\MyDLL.DLL That way - your DLL is always the same version on every PC (when you initially copy and register it - assuming nothing updates it later). While you can simply register a DLL in NETLOGON directly, I've seen a few nasties when NETLOGON hasn't been available and that DLL was needed... better to be safe than sorry IMO Your absolute best-bet is to run this as a PC Startup Script (which runs as NT AUTHORITY\SYSTEM) - so it registers it before your users even login, which is great if said DLL is needed at login time or desktop-creation time HTH Az

At home I've got XP Pro SP2 (not SP3 yet - tempted tho) - I run Server 2008 and no Vista in sight. At work - XP Pro SP2 all the way with a few Server 2008's creeping in. I admit that Vista will probably make SOME kind of appearance here on site but until then - I'm breathing easy and sleeping at night. Az

I think your local users would have to be Local Admin as you've said to be able to CHANGE TCP/IP settings - but any user as far as I'm aware can view. It's also entirely possible that every user on his network was a local admin once, but I don't know... can Power Users not actually change this? Az

If I recall, this setting is inside group policy. Open up a policy in GPMC and take a look here: User Configuration\Administrative Templates Then - Network\Network Connections. It MIGHT be the 'Prohibit TCP/IP Advanced Configuration' setting or it could be one of the others - I don't recall immediately off the top of my head which one it is - but take a look around that area. You could try taking them off 1 at a time until you get desired result, not the best way to do it but it may be quicker than guessing. HTH, Az