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