LiquidHonesty

Both machines have IE7, and one had MSN Messenger......one did not. I had a feeling it might of been a problem with IE7 because Firefox worked fine. I tried uninstalling IE7 but it still threw the error by that point Thanks for the advice!

I read on a thread on here (might of been Neowin) that it does. Even after the repair Device Manager gave an error. So I did a complete format/reinstall to fix it. Note, this is the 2nd machine this happened on as I tried it on another machine that DID have system restore turned on so I could roll it back. Both had the same problems.

It fixed my install by booting to the XP cd and doing a repair. But anyone know why it did this in the first place? Seems like the install doesn't backup the WININET.DLL file......any idea why?

I have a fresh install of XP SP2 on my system as I just got a new Intel Core 2 Duo. Anyhow, I installed XPize 4.5.1 and all went fine. I, however, decided I wanted to remove it because I was going to try out StyleXP, and here's when the nightmare hit. After removal, anything relating to IE gives me a WININET error. IE won't even open websites you type in, won't download files, etc. Other programs, such as MSN Messenger also give me this error. I have System Retore turned off, since it hardly ever works anyhow...so my only option was to reinstlal XPize. I did this...restored the "look" but I still get this error doing about anything, thus my machine is basically unsable (I'm posting this from another machine...). I checked my backups, and there is NO backup of this file, which I find odd since other threads I read on here looking for help said it does in fact edit this file. But there's NO WININET backup. So, anyonly have any solutions or am I going to have to "repair" windows with a repair install? I'm NEVER using XPIZE again if it's this easy to mess up your system, sheesh. Anyone have any ideas?

I can, but it's a simple script that just creates an account. That's not the problem, the problem is I need it to write it to a specific domain controller (a local one) instead of the one it usually connects to (systems office). It SHOULD create it on the local one since the local one authenticates the script user, but it doesn't. Thus I just wondered if there's a command I can write into the script to make it write to a server at a specific IP as opposed to the one it's writing to.

This would require setting up access to the DC for the library staff so they could create the accounts. I don't wish to do this nor train them how to do it. I use a VBScript that prompts for "name" "address" etc for the person and then automatically creates a RANDOM user with a RANDOM password that works for 24 hours. The problem is, it creates that account on the primary DC at the system's office which is 100 miles away and not replicated for 15 minutes or so. For creating accounts by hand, yes I log into the local DC. But as we have around 20-30 community patrons a day, I'd spend a lot of my time making new accounts for everyone. Hence why I created the script to allow the librarians to create it themselves... Oh, and it's 2003 Native but they've slowed the replication time down to help with speed issues. We have around 100 DC's across the state of KY that it's replicating to. That's why I want to be able to have the script create on my main DC first. I hope that explains my situation better..........

Ok, here's the scenario. I'm on a statewide education domain that consists of having DC's at all our locations across the state, and 3 "main" DC's at the headquarters. I have created a vb script that lets us create generic login accounts that expire in 24 hours for community patrons that wish to use our public access computers in our library. The problem is when I run the VBscript on a machine here on our campus, it creates the account on the main DC's at the system's office, and not the local one here. It takes 15-20 minutes for the account to replicate down to the local DC, which is what the machines use for login authenication. Thus, they can't use the account for 15-20 minutes til after it's created. SO, is there any way to force the script to create the account on the LOCAL Domain Controller so that it'll automatically allow login...and it'll filter UP instead of Down? We login to the local DC to reset passwords and such so that this replication "lag" doesn't affect those problems...but I'm not sure how to do it with this script. Any help is appreciated!

My XP does show the pdf thumbnails, but the pdf's have to be created with Acrobat 7 I believe it is. Could also be that I have Acrobat Pro since I create .pdf's all the time for work. I haven't paid attention as to if it does it on my laptop which just hast he reader or not.

There are some differences, but you can run regular XP on a Tablet just fine and add on most of the tools. Tablets came to the market before there was a "tablet pc edition" after all. However, on our tablets we install tablet edition now that it's out.......works better with the built in tools/tweaks.

Good to know! My only experience was with the Gateway CD's.....and that was some time ago. Wouldn't allow you to install to a non-gateway machine.

That's ok, I just had to ask. I can make do with just the UN as a simple query on the domain gives me the actual name if I need to figure it out. Thanks again for ALL your help!

Ok, last question I promise.......is there also a variable I could use in the vbs script to write the user's actual name, not their username? Like the name that shows up on the Start Menu if you use the XP style start menu? Like how it uses %USERNAME% to pull the username, what about the actual name?

It's bloated and slow.......but what good's a computer if you can't have the stuff you want running, running?

If it's anything like the Gateway XP cd's we get with every machine we order, YES. They'll only install on Dell machines (Gateway machines in our case).

Sweet! I'm going to try them both on Monday when I get back to work

Do you get this error in windows or in setup? If it's in windows so it actually sees the drive, you just can't do anything with it, right? If it's in Setup, does it once again see the drive but can't do anything with it? You can try F6 if you have the drivers your SATA drivers, otherwise that won't help much. But still, if you've done it once it should do it again UNLESS something you changed in the Bios was something you shouldn't have touched........but you said you cleared the BIOS, did you reset all the BIOS settings?

The logoff.exe can be renamed to something else, and a small program can be written to replace the logoff.exe, to perform whatever is needed before executing the real logoff program. Hrm, this is a thought. Can you create .exe files from .cmd? Also, if the file can't be written (ie, network is down) will it go ahead and execute the logoff command?

Have you changed your BIOS since the first install? By a standard rule, if it detects it no problems one time, it'll do it every time. I've done it many many times. If you've NOT updated your system bios and you are using the EXACT same Disc to install XP........you can try using a newer XP CD (slipstream SP2 and such) and go ahead and update your system BIOS and give that a shot.

Best bet is to plug the HDD in as a slave on a machine that boots from another drive and see if you can access it to pull data off.

Ok, for reference I found it out....if you use >> instead of just > then it adds it to the same file. Thanks again Janus, this will work just fine. However, if anyone knows how to get it to write a logoff as well, please let me know.

Ok, I think I got part of it figured out. Seems it was stopping at the "Fri" part of the date and dropping off due to the space. I changed the file creation to ComputerName_Random.txt and I think this will work just fine actually. HOWEVER, any way to increment the same text file instead of creating a new one each time? To make it just create a new file if there's not one there, and if there is just add a line?

That kind of works, but it doesn't increment the file, instead each machine just over writes the existing file that's already there which it seems to name "Fri" which I assume is for Friday and it has no extension. This "Fri" file's contents look like this: username:EMITCHELL0001, workstation: SOM-GHOSTLAP, time:17:34:21.92, date:Fri 06/02/2006 06/02/2006_28078.txt But we're on the right track....thanks a ton for this. Also, any ideas on how to log when they logoff?

Ok, here's the jist of what I was wondering if it's possible. I currently have computers in a student computer setting, customized, that work fine. They're all Windows XP SP2 and all the machines are members on a 2003 AD Domain. Each user logs into the workstation with their own AD UN/PW. What I'm wondering is if there's a way to make a script run or something else so whenever a user logs in, it records their USERNAME and the MACHINE NAME that they're logging into and Date/Time, to a text file somewhere. Each machine records to the same file, etc. A database would work too, anything! We need this to keep track of what user was on what machine and at what time. (Note, I can't just look at the machines to find this data out as I use deep freeze and thus all data is removed off the individual machines nightly). Thanks for ANY help or direction pointing you all can provide!

Windows Version?? I'm assuming XP. If so go change the user account type to "user" and they'll have more permissions.