InTheWayBoy

Just to give a point of view from the other side... I have several tablet's at my organization, and all are Toshiba's. Now this is almost industry wide, but Toshiba doesn't provide any source installations for anything really...just got two in and they make you create the restore media on the unit! It's a ghost image, and a protected one at that. And even though there is an I386 folder (Which is mangled to hell with OEM junk) there is no CMPNENTS folder that has the actual TabletPC stuff. So my solution? Obtain a release like mentioned here. I had no other choice really, Toshiba wouldn't budge, Microsoft doesn't sell it, and we don't have TechNet. I attempted to use the previously mentioned I386, but it didn't work out so well since I stripped out a lot of junk OEM drivers and such. I compared the release with other media and there are differences, but only in files you would expect it (TXTSETUP.SIF, WPA stuff, etc.). Now that might now be quite like what he is wanting to do, but I just wanted to show a possible scenario I think everyone can understand.

RIS on each of the local DC's. Check the RIS subforum for more info on that subject. As far as making sure all the DC's have the same installs that is where something like DFS might help out, but I can't comment on how to setup or configure that. And from what I read on the Vista installation there will be two HALs...32 and 64 bit. But each of those will fully cover their respective installations. It's kinda neat, you make a base image and then inject the extra drivers you need into the image. All that is happening is that the drivers are put in predetermined places, much like the $OEM$ folder idea. But I guess the finally made it automated so the imaging process will always process the files each time. So you can add or remove all you like. I only wish this would be backported or whatever to XP...we can only hope.

I too fought with this but ended up just forgetting about it. However, I did wonder what would happen if you simply renamed the file that starts the install...setup2.exe I think (At least that's how you manually run it). So since it's renamed it should fail the install, and hopefully without any error message. Next you could invoke the setup through whatever you want (GUIRunOnce, WPI, etc) and add the syntax to make it silent...it's kinda a lame way to accomplish it, but it should work. Just never really had the time or need (Use VM's now, never install again) to test it out.

I recently started picking apart our Dell XP install images. They are a pretty standard unattended, but it has support for several RAID/SATA controllers built-in. I used WinMerge to find the differences, and the most changes where in the TXTSETUP.OEM file you are talking about. There are also some random entries in the various hive.inf's, but as you have found out most of it can be done in that one file! It's pretty swank, I didn't slim it down as you have, but I did use their files as a base to integrate the Intel SATA drivers onto a vanilla OEM WinXP, as well as a Server2K3 unattended. One thing to comment on, in the Dell image there is no need for any OEMFiles part, as all the files are integrated into the source. I believe that's where the extra edits in the hive.inf's come in, helps complete the circle I guess. Instead of just the *.SYS file, the Dell image has all the support files for the drivers...inf's, cat's, dll's, etc. So in the end it's more work but cleaner in that you can (possibly) skip the OEMFiles.

I know when I first tried this I had lots of problems...first you need to find out what is happening. Run a results report for the GPO that installs Office. Assuming you are using GPMC it's built into the interface. That should tell you something like "Access Denied" or some error message. That should point you in the right direction. If you are getting the access denied I would triple-check your share and file security settings. I find the best results are to open the share permission up to everyone and then tighten down the file security. In my scenario I was trying to deploy Office to all computer regardless of what user logged on. However that wasn't happening, and that's when I traced it back to access denied and realized that even though I have the user security group being able to access the share, I wasn't allowing the computer security group access to it...and since the computer was installing this and not the user, then that was my problem and my fix. Maybe a little more info from the results report and also if you are trying to deploy this to the user or the computer will help. Good luck!

What you are all are looking for is called Folder Redirection, at least in regards to AD/GPO. What that does is tells the local computer to look to the server for various locations. GPO only supports four different properties for Folder Redirection: Desktop My Documents Application Data Start Menu All that's really happening is the GPO is editing several registry entries that tell the OS where things are. They are all located here: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders If you look there you will see more than just four entries...a common 'hack' is to use this to redirect the location of your Favorites. Best way to accomplish this in my opinion: 1. Createa a share with the correct permissions for your users (\\server\share) 2. Each user should have their own folder in that share labeled after their username (\\server\share\username) 3. In each users folder create a folder for each item you want to redirect (\\server\share\username\desktop) 4. Create a script that will map a drive using the username of the current user. I use AutoIt and it looks like this: MapDriveAdd("X:","\\server\share\"&@UserName) 5. In that same script, but after the drive is mapped, have another line perform a registry edit like so: RegWrite("HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders","Desktop","REG_SZ","X:\desktop") What this does is map the main folder for the user as a drive (X:\), and from there the script changes the registry to look to the correct folder in that mapped drive. I find that it's more reliable to do this to a drive than an UNC in case you were wondering. You could skip the whole drive mapping portion and just go straight to the server. This, in combination with roaming profiles is a pretty solid package. Since the major stuff is redirected the files that are transfered with the roaming profile with be small in most cases. As for the Offline Files question, this has always been a pain for me. I know one thing to look for is the share properties on the server. There should be a section that gives you three caching options...can't remember the exact location, but it's accessable via right-click > properties on the share. There is an option to never allow files to be used online, and I think that will effectively trump the local machines attempts to use offline files. Also, there are GPO settings specifically for Offline Files, and there is also another for disabling the automatic offline files for redirected folders. I can't give locations at the moment so you'll have to dig.

Can't comment on the permissions issue, but I can chime in on the LimeWire "Shared" folder...roaming profiles only handles certain folders in the profile directory. For example, the "Local Settings" folder isn't involved in the roaming profiles (Hence the name). Since LimeWare has bad habit of using a folder in the profile instead of a folder in your My Documents, that will never be apart of your roaming profile. I don't even think there is a way to include extra folders via AD...you could construct a logon script that would help with this, but I really don't think it's worth the time. Keep in mind the stress that will be put on your network is your roaming profiles grow large, say from downloads. It's best to keep things like that either local to the computer or have it setup to stay on the server through mapped drives. Each time that user jumps to a new machine it would have to transfer all those files, which not only slows down the logon for the user but will cause issues for other users as well.

Okay, so I was in a bind and had to load up a laptop using a standard Dell XP SP2 CD. Installation on those is slightly different than a vanilla XP install, but it's very minor tweaks like include CDKEY insertation (WINNT.SIF) and it integrates a few SATA drivers (TXTSETUP.SIF). Using this CD you have to go through the mini-setup as the WINNT.SIF contains no switches other than the CDKEY and a few other odds and ends. Now here is the odd part, I didn't join the domain during setup so I was going to make a temporary account to do updates and tweaks and then join the domain manually. At the screen where it asks for the user names I decided to use "local" as the user name...why, I don't know. But when I get to the Welcome screen the only user listed is Administrator...interesting. Where is the "local" account? I log in and go to users and it's not there...not that I mind in the end cause I really would rather do all the tweaks under the admin account anyways, but I didn't have a choice given that the CD wasn't unattended. But it looks like maybe use "local" as the user is some hidden way to bypass user creation? Is this something that everyone already knows and I'm just late to the party? I don't have time at the moment to verify on another computer, so if someone else want's to try that see what results they get that would be great! I would be happy to list all the changed files that Dell adds to the CD, but from previous attempts it's not much...mostly the extra SATA drivers and the files needed to work the activation thing. I will try this out later on a VM and see what I get, both with the Dell CD and an original CD to see if it's repeatable. And if this is common knowledge, are there any links that might help explain how/why this works this way? Thanx in advance!

There is also a group policy that can do this as well...normally that is only necessary in a domain environment, but you could do it locally too: Start > Run > gpedit.msc Administrative Templates > Windows Components > Internet Explorer > Security Features > Restrict File Download In that there are a few options...I can't recall off hand which is what, but it should be pretty obvious. After you change the setting it should instantly change, but you may have to reboot in certain cases. As far as automating it, I haven't dedicated the time to see about that...maybe someone else will chime in with that. Good luck!

You won't find those files/folders because you need to create them...open notepad and save a blank file as "WINNT.SIF". And use those "" as it will prevent notepad from adding the default .txt to the end resulting in WINNT.SIF.txt and that won't work. The $OEM$ is even easier since all you have to do is create a new folder and name it $OEM$. Create any additional folders inside of that manually as well. I've never integrated any x64 stuff, but for integrating F6 drivers I like to manually insert them into the source files. Seems to be a little more reliable that way...and you wouldn't need edit/add a WINNT.SIF or $OEM$ structure. You can find a walk through for it in the Device Drivers sub-forum.

Well 2003 R2 has a new feature that helps out with this, but even with that I always have to go to a new users computer and make sure everything is okay. Of course 2000 doesn't offer it, but I just wanted to point out it's still an issue in most cases. There are several ways to handle it, mostly depends on your setup. For instance, I have three buildings in my organization. I have three OU's, on for each building. In each OU are all the computers for that building. I then have three printer scripts GPO's, one for each OU. At the parent OU I have them all linked, but filtered to only hit the child OU that it needs to be. Sounds confusing but it works well enough. Of course if you don't have this structure then that is useless to you. As far as batches to do all this, I've never found a magical one that works all the time. I've used KiX and AutoIt, and both have support in some for for printers...either built it or via UDF's. KiX is designed from the ground up to be a login scripting language, so you might get the best results for that. You could also do this with vbs I would imagine, but I don't know how. Check this forum out: http://www.kixtart.org/ubbthreads/postlist...t=0&Board=UBB12 It's for all the user created UDF's, which are extensions to the basic language. There are printer scripts to find out which printers are already installed, others to remove, and finally some to add. Of course you'll have to take that and make it work for you, but it's a start.

In regards to the driver issue, if you can extract it to where it's the bare files then you should be able to copy them over to the %WINDIR%\INF folder, which would allow windows to find the driver easily whenever the camera is plugged in. However, upon further investigation it doesn't look like that's an option...however, it does have an iss script that might be able to be customized. I've never done it myself, but I see that a lot in the Application Installs forum. You might wanna peak in there and see what you can find. And as a final tip, someone recently created a universal extractor that might be able to pull the driver files out of the setup files. I don't have a link handy, but I believe I saw it on either the Application Installs or the Unattended Installs forums. I have a Sony Memory Stick Reader that has a similar setup and I just gave up...they don't like to make it easy for us for some reason! Good luck!

@Nois3 Sounds like you know your sh*t...I'm jealous! I picked up on your points about loading fresh reg setting via cmdlines.txt. I am very interesting in knowing more about this...specificially, I want to try and create as basic a user profile as I can. I'm looking to use that as the default profile, and then do all reg customizing after the fact via scripts and all that noise. But I've never really found any info that specifies what are the minimum entries/values to create a profile.

I run into that occassionaly, haven't tracked down why yet. I do know that if you let it sit there it will go through unattended. I just gave up and learned to live with it...

Another option is to create a Default User like suggested, but place it in \\%SERVER%\NETLOGON\Default User. Whenever a new user logs onto a machine, it first checks to see if there is an existing profile...if there isn't, then it checks the network for one...if none there, then it checks the local computer for one. Just another idea to toy around with.

I found this to be the easiest way to handle that issue: http://www.uawiki.org/doku.php?id=wxp:ua:i386 Basically you just script a copy command to run from cmdlines.txt

My organization got duped into by this questions electronic medical records (EMR) application called eClinicalWorks. Turns out it's not what we need, and while it's benefits are nice it's driving me mad. The whole thing is nothing more than a slick java application, running ontop of several open source technologies like Apache, MySQL, Tomcat...basic things you find in an decent *AMPP project. You install those on the server, and then it has a local win32 application that handles the client. It's licensing costs are very low compaired to the rest of the ones we reviewed, but we are all starting to see why. They don't offer 24/7/365 support, which is a joke being that it's healthcare. And the support they do have is worthless...they call back the next day, they are all Indian (They moved to Boston, made the thing, and then brought all their family over to staff it! LOL! I kid, but that's pretty close to what it's like there) and very hard to understand, and they are royal pricks about releasing info. For instance, due to them offering the worlds worst support, I've been trying to coax them into giving me the installation notes for the server. The client install is your standard installshield, but since the server requires tweaking to all the previously mentioned services they like to do that themselves. They originally started out as an EMR for small practices, typically ones that also don't have full time IT. So they keep stressing the hard installation instructions, only offering a certification process which costs money and time...for what, to configure Apache? Now not that I'm some uber-geek, but I hold my own...in fact, I've already repackaged most of their installs because even the client requires multiple actions to properly install. So I'm gearing up for attack mode, figure if I can't get it out of them nicely then I'll try and be a royal prick and see where that gets me. One of the things I see as being a problem is their open source licensing. I have a general idea of what that entails, but I feel like they aren't living up to their end of the deal. Since I don't get an install CD (They do the whole server install remotely) I don't have access to source, and they don't offer it easily off the web. From what I know that's a no-no right? Also, don't they in turn have to provide their source for applications based on the underlying open source tech? I remember it not requiring support files (System applications, updates, etc) but the core stuff that runs off Tomcat and Apache. Also, doesn't open source also require that I be able to distribute it freely, at least those sections covered under the license? Again, with their current setup they don't allow that, even going as far as password protecting the install .exe's and not giving out the passwords to us...of course I threw a keylogger on it and grabbed it that way. That's what really burns me, is that I continue to reverse engineer their support from all angles and have a better understanding than some of their techs do, yet they won't give me the simple things like the install process for a server. As I pointed to them what happens if the server goes down Friday at 6:00PM? Currently we wait until Monday, which isn't an option with healthcare. My superiors are now starting to see my way, and are also pressing them on issues...we figure if we're stuck with it we ain't gonna make it easy for them. Get this...their support forum isn't even run or funded by their company, it's by a fellow user! While I applaud the user in his gifts, it's amazing to me that no one thinks it's funny the thing doesn't have it's own official forum! And since the forum is the easiest way to get past the language barrier it's important that it's always there...and yet they don't even fund it! At least pay for it, then let the users support it. GRRR! This is why I've been so abscent, dealing with this horrible package. Things continue to go sour I'm gonna make it my lifes work to run them outta business! So to summerize the questions: 1. Do they need to provide the source for Apache, MySQL, Perl, Tomcat, etc as well as their code that runs off those? I know there are ways to restructure your code to charge for it, but how is that defined? 2. Can I just hand out the open source parts, specificially theirs? 3. If they are in question on these, can I press charges, or does the open source people have to do that? That would be fun! That's all...I imagine I don't have as much clout as I think I do, but I want to know that I can backup what I say. Thanx!

I know to remove bluetooth from XP (Which I need to do...thanx Toshiba!) I just edit the txtsetup.inf to not use bth.inf...so I would assume adding that to txtsetup.inf, along with all the support files for it (Likes like chilifrei64 gots a nice list there) would be enough. Of course that's about the lowest level of integration I can think of, but manually doing it after install should work just as well.

Was looking for a new way to manage regtweaks, and found this little gem: http://www.registrytweaker.net/ Looks to be perfect for UA's. Not only does it have a very nice reg tweak section, but it also has some nice extra's too! I haven't had much time to test it out, but first blush it looks really slick. What you all think?

I haven't bothered to compare, because VMWare Server is excellent! The only lacking feature is that it doesn't support multiple snap-shots like VMWare Workstation does. Otherwise it's slick...I'm sure VS2005R2 is nice, but VMWare is the definitive vm application.

Hmmm...that is a good question. I know that's how I did it when I needed local admins for a while, but I never checked to see if it over-writes anything. I believe it does though, so be careful.

Get friendly with the Event Viewer...that should give you most of the info you'll need to worry about in regards to your first question. You can even run it on another computer and have it check the server, so you don't have to work on the server. Of course even that is flawed, but it's a free and useful start.

I was playing with an desktop management application (Desktop Authority), and it looks like it used mapped drive checking to accomplish this. I guess it would check with the server for open sessions to certain shares, and then if it found one it would log off the other logins. Or something like that...just an idea if you are wanting to do it all using scripts.

I too am just getting into the wonderful world of KiX...I still like AutoIt better for most things, but it doesn't have the InGroup feature that KiX does. I can't comment on the other questions, but another option for running the script is to create a GPO that does all the dirty work. Here's a nice post explaining it in more detail than I can: http://www.kixtart.org/ubbthreads/showflat...939&an=0&page=0 The idea is to have one location for your kix32.exe, then use GPO's to run the various scripts you need. Even if you only have one script this is better because the GPO can be easier to handle, and when you get into needing various scripts it'll pay off big time.

I can vouch for this, if you run that disc on another computer it would still install but ask for activation. They use some of the slicker product activation schemes. They also have integrated Intel SATA, that work even without the unattended.sif.