x243

I made a silent ICQ Lite (v5.04) installation that: 1.) Removes & deletes the toolbar that is normally installed during an /S install 2.) Removes the ad banners in the program and message windows 3.) Deletes the extra unneeded shortcuts that are created on the desktop and on top of the start menu 4.) Deletes the default sounds. I did this because I hate the foghorn sound and "uh-oh" sounds. If you want the sounds, you can edit icq.bat in the archive, remove the line that deletes the sounds and then re-add the batch file to the archive. I haven't seen a package like this on MSFN, so if someone already created one then ignore my post. For all 5 of you, including me, that still use ICQ here it is: http://rapidshare.de/files/15924536/ICQ.exe.html It could probably shrink another 1MB if it were made into a 7zip package, but I prefer WinRAR.

1.) Uphclean integrated as a default 'automatic" service 2.) .NET Framework 1.1/2.0 as an installable option from Add/remove programs or during unattended installs 3.) WU6 with Microsoft Update and WGA (although unecessary for 2k) integrated 4.) Windows Installer 3.1 & BITS 2.0 Update (I think you're already planning for this right) 5.) Root Certificates Update (latest) integrated That's all I can think of for now...

http://www.windowsitpro.com/Articles/Print...ArticleID=46896 http://www.neuber.com/taskmanager/process/spoolsv.exe.html I've seen problems with Lexmark printer drivers and also Normal.dot corruption. I'd recommend deleting the Normal.dot file if it is larger than 85kB. You can find the Normal.dot file in your profile folder inside the Application Data\Microsoft\Templates directory. Word will recreate the file the next time you open it.

Seeing as large HD support was added in SP3 and this is a cumulative SP5 then it will be yes <{POST_SNAPBACK}> Should I add it to USP 5.0 then? It's not complicated at all - it's just not enabled by default in SP3/4/5 <{POST_SNAPBACK}> As a follow up on my previous issue, I noticed that textmode setup now shows the proper size of my drives and has no partition detection issues. I added the bigLBA settings to SETUPREG.HIV, but I can't be sure it was that setting alone that fixed my problems.

Those two components are easy enough to add during the cmdlines.txt portion of setup. For .NET Framework, use RyanVM's compressed installer which doesn't require any switches and for Windows Media Player 9, the syntax goes: MpSetup.exe /Q:A /R:N /c:"setup_wm.exe /Q /R:N /NoPID /P:#e" You'll still need to do security updates for WMP9 after install finishes though.

Why do you keep trying to do something that SBS 2003 was not designed to do? I posted the answer to your question in your previous thread along with the answer to your previous question. I don't know what part of "Windows 2003 SBS will only run in Remote Administration Mode and is limited to 2 simultaneous terminal services sessions by System Administrators only" doesn't make sense. This limitation is placed at the kernel level, and any attempts to circumvent it result in the kernel changing the settings back they way they are supposed to be.

I think I've narrowed it down. nlite is causing the Recovery Console problem. If you choose to remove Windows 2000's SCSI drivers (I never use a single one of them), it screws up the Recovery Console file list later on. There must be a remnant of the file list in some SIF file or something even after nlite removes them. I removed more than just the SCSI drivers, but I'm pretty sure that is where the problem lies.

I'm not sure what you're saying about svcpack.in_. Do you mean the inf file needs to be extracted into the i386 directory, or it needs to be cleared completely? I was under the impression that changing anything in that file would cause a problem during installation, let alone during a Recovery Console install.

I haven't used Windows 2000 since I went AMD 64 last year. I could almost swear though that I never had a problem in textmode with drives larger than 128GB... I have been using 160GB and larger drives for several years now and Win2k was my OS of choice until last year. Editing the LBA in HIVE file was something I had thought of, but does that actually have any effect in textmode?

Do you mean it doesn't work during a "x:\winnt32 /cmdcons /unattend" installation or when Windows itself is installed unattended? I was not able to install the Recovery Console even using "x:\winnt32 /cmdcons." Currently I'm running Windows XP due to another problem I found with SP5, which may or may not be related to nLite's downsizing of the source. Last night when I thought I had the "perfect" SP5 unattended CD, I decided to burn it and install it on my main machine. During the initial stages of textmode setup, Windows would not detect the size of my 200GB harddrives correctly. They were limited to 131xxxMB (i.e. 128GB) and I could not partition the drive correctly. So I made one 128GB NTFS partition and let Windows install. I found that GUI mode WIndows detected the drives capacity just fine. I figured there may be a problem with the atapi.sys, or is there another file that governs drive detection during textmode setup? The problem didn't appear in the multiple trials I did in Virtual PC, but then I was working with only a 16GB virtual hard disk. I've tried slipstreaming SP5 from a original (no SPs) Windows 2000 source, and then also slipstreaming SP5 into a Windows 2000 SP4 source, but the drives are still detected as 128GB in textmode. As for WINNT32.log, this is all that appears after trying to install the Recovery Console: Detected 192 MBytes of memory.

Perhaps I'm doing something wrong, but I can't install the Recovery Console locally using a slipstreamed SP5 disc. At first I thought it was because I used nLite to remove some features, but even using a complete CD, I can't get it to install. The error is that "setup was unable to build the list of files to be copied" the data is invalid. I always install the Recovery Console locally at the guirunonce point and it has always worked.

The 5 CALS that come with SBS 2003 are not Terminal Services CALS. TS CALS run at about $80 per license. Remote web workplace is your cheapest option and it will work for 6 people provided you have 6 XP machines and each person connects to his/her own computer which is already configured to each person's liking. The only other option is to set up a dedicated terminal server, in which case you still need TS CALS for it.

http://www.microsoft.com/windowsserver2003...generalfaq.mspx "Q. Can I run Terminal Services in Application Server mode on Windows Small Business Server 2003? A. No. It is not possible to run Terminal Services in Application Server mode on Windows Small Business Server 2003. This is a change from Small Business Server 2000. Running Terminal Services in Application Server mode on a domain controller may present a security risk to your network. If you want to use Terminal Services in Application Server mode, we recommend that you purchase an additional Windows Server 2003 license and install an additional server running Windows Server into the Windows Small Business Server 2003 domain. For more information, see Deploying Windows Server 2003 Terminal Server to Host User Desktops in a Windows Small Business Server 2003 Environment."

Thank you.

Windows 2003 SBS server only supports 2 terminal services sessions since it is limited to the equivalent of Terminal Services Administration mode in Server 2003. The tradeoff for terminal services is the Remote Web Workplace feature which you access through http:\\server_url\remote. This will let you connect to any Windows XP system on the network so long as you ran the wizards correctly which force Remote Desktop to be enabled on all Windows XP client machines by group policy.