cluberti

Have you done the following, as per these MS KB Articles? http://support.microsoft.com/default.aspx?...;301527&sd=tech http://support.microsoft.com/default.aspx?...;306800&sd=tech http://www.microsoft.com/technet/prodtechn...3ee87c5658.mspx You may have already seen these, but they've got most of the information you'd need to troubleshoot Remote Assistance. The error code you're seeing (0x80070005) maps to an "Access Denied" error message, so it could be a configuration issue on one end or the other, but I'm not entirely sure which. Hopefully the above URL's will help, but if not, perhaps you could post specific data about who is offering the request, how they're offering it, etc.

You can't install SBS 2003 into an existing network containing another SBS server - it has to be the only SBS server on the WHOLE network, or it refuses to install as a DC. You might consider not using SBS 2003 in this situation, if you've got an AD to migrate, or you will have to install SBS 2003 as a new domain, create a trust, and move user accounts and mailboxes over... I'm not entirely sure you had two SBS servers on the same network, because it's not possible. Here are the limitations of SBS (these aren't able to be changed, either): Only 1 SBS Server on a network. Only 1 Domain. Only 1 Forest. The SBS server must hold all the FISMO Roles. The SBS Server must hold all the Server Applications included in the Suite. SBS does not support clustering of any kind. Maximum of 75 users and/or devices total. Those are built into the software - you sure both SBS servers were the same version, and on the same network?

Usually, installations via CD media are a bit faster than network installations on most 10/100 networks, but I've found that since migrating to gigabit to the desktop (and 10Gb on the server network), network installations are just as fast. Network installations via RIS are more convenient for me, too, because I can allow anyone on my domain the ability to RIS their own machines if a problem arises - if I need a reinstall, I just prestage the machine in AD, have the user reboot and press F12, and come back in a few hours to a fully-functional machine. I don't have to provide anyone with installation media, and I don't have to be there to do anything either .

You'll likely have to use WinPE (or BartPE) to boot into first, and use command line options on winnt32.exe to make sure that the IDE drive is C:\, rather than D:\.

If it's server 2003 and the drives are NTFS, you can use the built-in NTFS quota management, or, if you've got Server 2003 R2, a much more robust Quota Management tool that can do file and folder quotas as well (rather than just user quotas on a drive or folder tree).

AVG is also free, and quite good. It runs on 2003 without issue.

Actually, it depends on what hardware is included on the motherboard - if you replace the motherboard, you do run the risk of having to re-activate due to changing of things like chipset components, possibly the audio controller and/or network controller, etc. - you probably won't have to reinstall, but you'll likely have to re-activate Windows.

What version of Exchange was the old mail server? If it was the same, you should be able to copy the database, log, and chk files from the old server to the new and mount it as a store in Exchange System Manager. You will need all of the relevant files, and you'll probably want to do a consistency check on them once you copy them back to the new server. And also slightly OT but relevant, having Exchange installed on a AD DC (of any kind) is ALWAYS a bad idea, unless it's a SBS Server (and even then, it's not the best solution).

New toys are cool - good luck. Remember you can email or PM me if you need any help.

Is there a particular reason you'd like to do this? It may not be legal to do what you ask, depending on which country you reside in...

The file system corruption is coming from somewhere - if the drives both check out fine on their own, install Windows one at a time on each drive, then try again on a new array. If it works on each drive but not the array, you'll know where your problem lies. There are no really good solutions to these types of issues - it's all trial and error, and wherever the error is, that's the problem location or configuration .

I'm not sure about why your reg file isn't working, but perhaps you could create an "unattend.cmd" file on your CD in \$OEM$\$1\INSTALL, and call it from [setupParams]. Again, make sure all of your .msi files are in \$OEM$\$1\INSTALL. In your WINNT.SIF file, you'd have the following: [GuiUnattended] TimeZone = xxx AdminPassword = * OemSkipWelcome = 1 OEMSkipRegional = 1 AutoLogon = YES AutoLogonCount = 1 [SetupParams] UserExecute=%systemdrive%\install\unattend.cmd Then, in your unattend.cmd file, you'd have the following: SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx REG ADD %KEY% /V TITLE /D "Installing Applications" /f REG ADD %KEY%\005 /VE /D "Adobe Acrobat" /f REG ADD %KEY%\005 /V 1 /D "\"%systemdrive%\Install\Adobe Acrobat 6.msi\" /qn" /f REG ADD %KEY%\010 /VE /D "BitDefender Internet Security" /f REG ADD %KEY%\010 /V 1 /D "\"%systemdrive%\Install\BitDefender Internet Security.msi\" /qn" /f REG ADD %KEY%\015 /VE /D "Dot Net Framework 2" /f REG ADD %KEY%\015 /V 1 /D "\"%systemdrive%\Install\Dot Net Framework 2.msi\" /qn" /f REG ADD %KEY%\020 /VE /D "MDAC 2.8 SP1" /f REG ADD %KEY%\020 /V 1 /D "\"%systemdrive%\Install\MDAC 2.8 SP1.msi\" /qn" /f REG ADD %KEY%\025 /VE /D "Nero 6" /f REG ADD %KEY%\025 /V 1 /D "\"%systemdrive%\Install\Nero 6.msi\" /qn" /f REG ADD %KEY%\030 /VE /D "O&O Defrag" /f REG ADD %KEY%\030 /V 1 /D "\"%systemdrive%\Install\O&O Defrag.msi\" /qn" /f REG ADD %KEY%\035 /VE /D "Windows Install 3.1" /f REG ADD %KEY%\035 /V 1 /D "\"%systemdrive%\Install\Windows Install 3.1.msi\" /qn" /f REG ADD %KEY%\040 /VE /D "Windows NT IP Config" /f REG ADD %KEY%\040 /V 1 /D "\"%systemdrive%\Install\Windows NT IP Config.msi\" /qn" /f REG ADD %KEY%\045 /VE /D "WinRar 3.2" /f REG ADD %KEY%\045 /V 1 /D "\"%systemdrive%\Install\WinRar 3.2.msi\" /qn" /f The script would run at T-9 in Windows setup, and your runonce installation would run on the first login (which would be done automagically).

If the system "hangs" like that, it may be prudent to make sure all of your drivers are the latest stable released versions from the respective vendors' sites, and that there are no known issues with the games in question running on XP 64. You may also want to try removing or disabling any antivirus applications as a test, to see if the problem could be caused by high I/O. Especially if the system comes back and continues after a hang, it's going to be a driver or high I/O issue (antivirus related). Are there any events logged in the event viewer that seem to correspond to times when the system is hung?

In this case, I think it would be best to run perfmon and/or poolmon on the system in question to find out which program(s) are misbehaving, rather than just sweeping the problem under the rug with a reboot or utilities that wipe memory. These are bandaids, not solutions.

Are the users using local profiles, or are their domain profiles roaming profiles? The laptop is trying to get the DNS information about the user's account in the domain, that's at least what the "GetUserDNSDomainName" relates to - if you've got roaming profiles, this could be the cause. If not, we'll have to dig deeper.

Actually, if you go with Windows 2003 R2 as the server OS, DFS is much better at dynamic data due to the improved replication schema and compression algorithms (it now only replicates changed data in a file, rather than whole files as it has with Windows 2003 SP1 (non-R2) and older versions of Windows).

If you are unable to launch any applications after a certain number of days, it's usually due to resource exhaustion - either in desktop heap, kernel nonpaged pool, kernel paged pool, or system PTE's. You can track most of these via perfmon, and I'd bet that if you ran perfmon from the time you first started up to the time you are unable to launch any new applications, we'd see a definitive reduction in one (or more) of these critical kernel memory resource pools. Just because your box has lots of free *RAM* doesn't mean it hasn't run out of *memory* - memory can mean many things in Windows, not just RAM.

For actual services, you need the "Server" service enabled for inbound connections to work, and "Workstation" service for outbound connections to work. You also need the RPC service functioning to make SMB connections outbound if there's ANY security restrictions in place, and you'll likely need the "Computer Browser" service enabled if you want network browsing to work.

If you import HKCU registry settings at T-13, T-12, or T-9 during setup, your settings will get applied to all users on the system.

Read the help for the Connection Manager Administration Kit (CMAK) - it's in there.

Well, I do have an answer, but you're likely not going to be happy with it - with that said: There are some limitations as to what can actually run in the "BootExecute" environmtnet: 1. Only applications can be run - not .cmd or .bat files, or any other type of file; only .exe applications. 2. The application must be a "native" application, meaning that it is linked with "-subsystem:native". No C run-time, no C++ lib, etc. Only applications that make calls into ntdll.dll. 3. The application MUST be built via the Windows DDK (Driver Development Kit) - with no exceptions. If it wasn't built in the DDK environment, it won't run properly in the "BootExecute" environment. If you want some more help regarding ntdll.dll, the "Native" NT API, and the "BootExecute" environment, read information found in the Windows DDK. Google might pop up some hits too, but the DDK has a pretty exhaustive resource for the "BootExecute" environment and, more importantly, the Native NT API. I believe the sysinternals site has some information regarding ntdll and the Native NT API as well, or at least it did the last I checked a few years back.

Mr. Snrub is correct - apparently we've made changes to the licensing agreement for Windows XP/2003 and Office XP/2003 OEM software (I'm not sure how I didn't know about it, but it does check out), so it appears that unless you're buying a whole machine from a vendor or are a Microsoft-registered OEM system builder, you aren't supposed to purchase OEM versions of Windows. Whether or not this will be enforced remains to be seen, but apparently the rules have been modified. On a related note, I have heard many complaints from 'net denizens, colleagues, and friends who've purchased OEM software in this fashion in the past and then had to call Microsoft for support, or a private hotfix - only to be turned away, because they purchased OEM software that came with NO support from Microsoft. Remember that if you're purchasing or providing an OEM copy of Windows, you (as the defacto OEM) provide Windows support.

This is the bible of Windows - anything you want to know about how Windows works, will likely be answered here, and in great detail. Just thought I'd throw in my $0.02 . I've read other books, but most of those contained information in the Windows Internals book. The "Mastering Windows Server 2003" book was a good book, however, and did have some nice diagrams and helpful hints for administrators. A good MCSE study book as well.

You can use Windows, so it must see some video card - what exactly is in your device manager, and what devices are you needing to install?

If neither have setup applications, you'll have to go into device manager and update each device manually, via the device's properties dialog box.