GetCool

Are we lost in space ? The original poster (remember him ?) wants his computer to go a bit faster because he's been using it for numerous years. Everything in this thread has been relevant. When one of my friends or family members (who are "average" users) runs the same Windows install for a few years and then asks me for help because their computer is slow, I almost always reinstall for them. But I know that if I reinstall and just leave it at that, in another few years they will be in exactly the same spot. It is exactly this reason why I invest the time in making images. If you can give an answer to a question that fixes the problem, great. If you can give an answer that fixes the problem and will prevent it from recurring, even better. That's all this was. I think I can safely assume that most users reading this forum are not just "average" users. Average users don't give a crap about tweaking their machines or getting them to run better or reinstalling. They want to sit down and use their computer, and when it doesn't do what they want it to do, they seek out the fastest solution possible which is to get someone else's help. Anything suggested in terms of automated installs and imaging can take days, weeks, even months to get right. But I assume that most people reading this forum can probably handle it if they choose to. It's really not rocket science. Most people who are considered "computer experts" are really just individuals who have memorized various nuances and patterns for accomplishing tasks in Windows... which boxes to click on and in which order. There are always multiple ways to accomplish a task. It's always up to the individual. If the original poster's machine is running slowly, he could spend weeks developing an automated install method that he could use over and over, spend just a day reinstalling once and forgetting about it, or spend only a few hours removing programs from his startup and running malware scanners/cleaners. It's up to him. I will offer my suggestions for how I would do it, and leave it at that.

You're right. It's an absolutely ridiculous amount of work. Thankfully I do not use that many programs, so for me it "only" takes 2-4 days to completely configure my system and all of my apps. BUT there's a much easier way. I don't know why you guys are talking about automating your installs. Why not just image? This was my process: First, I reinstalled Vista. I spent about 3 days installing all of my drivers and applications, and configuring my whole system. I ran every application, configured every setting I wanted to, tested the applications, then ran my system as-is for about a week to see if I discovered anything else I wanted to change or anything that was buggy. Once I deemed my system "perfect" I burned myself a RIP Linux CD and booted from it. I plugged in an external USB hard drive that I am using exclusively for system images (but you could use any device with unused space). At the Linux command prompt, I ran the utility cfdisk on the device (in my case it was recognized as /dev/sdb in Linux... make sure you know what device you are working with before messing with the partition table): # cfdisk /dev/sdb I followed the prompts to create a Linux partition on it (which must be at least as large as the amount of space your Windows partition uses), and wrote the changes to the partition table. Next, I created an ext2 filesystem on the partition I just created: # mke2fs /dev/sdb1 I then created a directory in which to mount the filesystem I just created, and mounted it there: # mkdir /mnt/backup # mount /dev/sdb1 /mnt/backup Next, I used the utility ntfsclone to create a backup image of my Windows NTFS partition (where /dev/sda1 is my Windows partition): # ntfsclone -s -o /dev/sda1 /mnt/backup/Vista_Backup_2008-12-20.img This creates the file Vista_Backup_2008-12-20.img on my backup device. I then unmounted the device and rebooted: # umount /mnt/backup # reboot And that is it. When I want to restore the image, I boot from the same CD, mount the backup device in the same manner, and use ntfsclone to restore: # mkdir /mnt/backup # mount /dev/sdb1 /mnt/backup # ntfsclone -r -O /dev/sda1 /mnt/backup/Vista_Backup_2008-12-20.img # umount /mnt/backup # reboot

Yes, it can take a very long time to reinstall Windows and get all of your applications reinstalled and reconfigured. The last time I reinstalled Vista and all of my programs it took me an entire weekend. However, most people overlook a very important issue: what happens if/when your disk (or filesystem) crashes irrecoverably? If you intend to run the same install on the same drive in the same computer for year after year after year, a disk or filesystem failure will become entirely possible (although still unlikely) over time. The odds of my disk/filesystem failing may be low, but so are the odds of my apartment getting robbed or destroyed in a fire. I still purchase renter's insurance as a safeguard against one of these unlikely occurrences. I strongly advise everyone to also have a similar safeguard against a catastrophe with their computers. If your disk dies, then you will have to reinstall everything no matter what. Same thing if your NTFS filesystem crashes irrecoverably; a reinstall will be required. And if this type of situation occurs, it will probably occur at the worst possible time. This is why I recommend reinstalling if there is a decent reason to do so, and then making an image of your partition. DriveImage XML is a good free program for making NTFS images, but I use something even simpler... boot off a Linux LiveCD (such as Knoppix) and run ntfsclone. If you take the time to set up a good, clean system now, and make an image of it exactly the way you want it, then you will save yourself TONS of time later. If you screw anything up, you just restore. If you accidentally install spyware, you don't have to bother cleaning your system; just restore. If your disk completely dies, you buy a new disk, partition it in Linux or WinPE, then restore. A good image of your operating system's partition is an invaluable asset.

I've been running various systems with no paging file for years, on both XP and Vista 32/64-bit. They all had 2 GB of RAM or more. My current Vista x64 system has 4 GB. Even with 2 GB, I never once had any problems working with no paging file. I run typical desktop applications, audio/video editing software, and games. I've even worked with Gigastudio (software synth) and multiple-GB sample libraries, which is a memory-intensive application. So, I think with 8 GB, you are more than safe. If you want to be 100% sure that you will never have any problem whatsoever, then I guess the best thing to do is give yourself a small paging file... but I have yet to encounter one of these programs that "expects" a paging file regardless of the amount of RAM. The only minor exception to this is Photoshop (at least older versions, like CS1 and earlier), which complains about the lack of a paging file upon startup, but runs perfectly fine after clicking "OK" and ignoring the error.

I'm having the same issue with 64-bit Vista, vLite 1.1 RC, and 4GB of RAM. Interestingly, with vLite 1.1 beta 2, all I had to do was integrate the hotfix and it worked. Installs could complete with no issues on 4GB of RAM. I have not tried integrating the hotfix using vLite 1.1 RC, leaving the "4GB fix" option unchecked, but this would be a good experiment to try.

Well, I just decided to experiment and figure it out myself. It appears that the NetBIOS over TCP/IP driver (netbt.sys) is called "WINS Client(TCP/IP) Protocol Driver" in nLite. Also, it appears that SMB is, for some reason, tied into the NetBT driver, even if you're not using NetBT at all. The NetBT driver is required to run even if you're not using any kind of name resolution and just sticking to straight IP addresses. I would suggest simply giving the NetBT driver the same name as appears in Device Manager, under "Non-Plug and Play Drivers": "NetBios over Tcpip". Seems reasonable to me.

First of all, I'm fully aware that NetBIOS over TCP/IP isn't necessary to access SMB shares, if you're just using direct SMB over TCP port 445. This is proven by the fact that you can go into the TCP/IP properties of your LAN connection, go to Advanced > WINS, and click Disable NetBIOS over TCP/IP. After doing this, you can still access SMB shares by typing a UNC into Explorer (\\hostname [if the hostname is resolvable via DNS or the hosts file] or just an \\ip.address). All of this was well and good when I was using nLite v1.0.1 and earlier. I could remove all the available networking components, and utilize all the available networking tweaks, with the exception of the Close Microsoft-DS port tweak, as this would close inbound and outbound TCP port 445 (see my previous post on this subject). However, since I started using nLite 1.2.1, SMB functionality seemed to break when I use this same configuration. Not only can I not enter a \\hostname into Explorer, but I can't even enter an \\ip.address. Upon investigation, I discovered that the NetBT driver is disabled (via Device Manager > View > Show hidden devices > Non-Plug and Play Drivers > NetBios over Tcpip). Enabling this driver allows SMB functionality once again. So, my questions are: Why is the NetBT driver even needed when you're not using NetBIOS over TCP/IP? What does NetBT have to do with anything when you're just using direct SMB over TCP port 445, and you're not using any name resolution (i.e. entering an \\ip.address directly in Explorer)? Given that NetBT is, for some reason, needed, which option in nLite 1.2.1 is disabling the NetBT driver? nLite v1.0.1 didn't disable the driver (I am assuming, anyway) when all the networking components were removed and all the networking tweaks were used (except the SMB tweak). Thanks for any input.

Yeah, and I can verify now that it is definitely the "Microsoft-DS" networking tweak that breaks SMB. While I knew that closing port 445 would kill SMB, I always thought that this tweak just closed inbound port 445. Apparently it closes it outbound as well. So, just to summarize: it is safe to use all of the networking tweaks, except for the port 445 / SMB tweak, provided that you don't care about NetBT and you're using DNS (or you're not using any name resolution at all, and just using plain IP addresses).

Nuhi, While I am sure that disabling all of the Networking tweaks is a safe, blanket way to ensure SMB functionality, I'd still like to know exactly which tweak(s) cause the problem. Looking over them again, it would seem that if you don't use NetBT, then all of the tweaks can be enabled except for the "Microsoft DS" tweak. Of course, this is just a hypothesis; I will disable this tweak through the registry and see if it works.

Well, I don't have access to my LastSession.ini at the moment, but I'm looking through the options in nLite right now, and I can say that I'm pretty sure I removed all the networking components, operating system components (save for a few command-line tools), and services that are available to be removed (on WinXP Pro SP2). However, looking through them, I can't see anything that suggests it would break SMB client functionality. The closest things I can see are: The TCP/IP NetBIOS Helper service, which disables NetBIOS over TCP/IP (NetBT). I can personally attest, however, that NetBT is not needed on a network that does not use NetBIOS. I have successfully connected to SMB shares (both Samba and Windows 2003) from a machine with this service disabled, when the networks used straight DNS for name resolution. The Map Network Drives/Network Places Wizard OS component. This shouldn't be necessary with the net use command. Furthermore, I haven't even gotten to the point of trying to map a drive; simply entering a UNC in Explorer doesn't work. That leaves, of course, the "Close Microsoft-DS port" tweak, which I know that I did enable. I would think that this would do just what it suggests--close inbound TCP port 445--but perhaps it has other consequences. I have successfully set up a Samba server in the past with only TCP port 445 open to the server. No NetBT, no 137-139, etc.; and Windows XP clients could connect to the shares just fine (using DNS for name resolution). I agree that SMB on Windows is confusing... every time I think I understand it, there's a new angle I dig up. Nonetheless, theoretically speaking, nothing on my network is such that it should break communication between my client and server. Given that, the problem most likely exists on the client itself, which points to an issue with my nLite configuration. I think reverting that one tweak is worth a shot. It will be interesting to see what it does.

I'm wondering if I removed something with nLite that actually broke SMB functionality entirely. Note that I'm referring to accessing SMB shares, not using my machine as an SMB server. I have a heavily stripped-down Windows XP Pro install; I cannot provide the exact configuration at the moment, but I do know that I removed all the available services and networking components. This configuration has worked fine for my needs, but I just recently set up a Samba server in my home, and now I can't access any of the Samba services from my Windows machine. Specifically, when I try to enter any UNC in Explorer (either \\hostname or \\ip.address), I immediately get a message about the address not being found (even with the server's hostname in my hosts file, etc.). Of course, it could be a Samba configuration problem as well (as I don't have another machine to test), but I have a lot of experience with Samba, and given the simplicity of this particular implementation (a single share), I am inclined to believe that it's fine. Anyway, I was hoping someone could tell me if there is a known way to remove SMB client functionality with nLite, since I don't remember any of the item descriptions stating as such. Thanks.