cluberti

I would then suggest using Virtual Server 2005 or VMWare Server 1.0.1 and build these CDs as .iso's, test in the virtual environment of your choice until it works, then burn to CD. No wasted media .

Treat your intranet as an "internet" - the same policies and concepts apply. I'm not sure I understand what you are attempting to do if the links posted do not assist you. Perhaps you could be more specific in posting your requirements or requests?

Do you have a VLA with Microsoft? If so, yes, contact your TAM. If not, not legally.

But is it broken (technically, not perception)? No. And possibly breaking currently working and shipping 3rd party and Microsoft application installers is not an acceptable solution. It's a no-win situation, but the private is available by contacting Microsoft - it's not like there's no patch, it's just not built and tested currently to the same level as a public hotfix, but if you want it, you can certainly call or email support and ask.

I would strongly suggest running regmon and filemon (both from http://www.sysinternals.com) while attempting to install the Windows Installer 3.1 update. If you are receiving an "Access Denied" error message, you will see that in either the regmon or filemon output - this will tell you where (either on disk or in the registry) you are being denied, and you can then resolve that issue and continue the installation successfully.

This is repairable by either going to the recovery console and replacing the file from the service pack files cache, or doing a repair install from the installation media. If you choose the recovery console option, it would be wise to rename the existing crypt32.dll file and THEN copy in a new file from C:\WINDOWS\ServicePackFiles\i386\.

I can second that statement - on 1GB of RAM, I find Vista's speed to be lacking at times (and it usually corresponds to high RAM utilization). When I add another 1GB of RAM, all of those issues dissipate (Vista Ultimate will gladly eat 1.5GB of RAM at idle).

- Autopartition=0 Unless you set Repartition = YES, you'll get prompted for partitioning during setup. - FileSystem=* As iTwins pointed out, this value must be set. I'd suggest ConvertNTFS, but LeaveAlone will still result in an NTFS volume if Autopartition = 1 and/or Repartition = YES - [Display] - BitsPerPel=32 This may not affect your ability to unattendedly install, but I would suggest setting the other values here under Display as well (XResolution, YResolution, and VRefresh) - [userData] - ProductKey="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" - ComputerName=MONEY - FullName="Money" You're missing the OrgName value, which will result in a prompt during setup for the organization value.

It's actually not MCE, but the physical drive's firmware that has this restriction. And yes, there's a 5 change limit, built into the firmware of the drive itself. Supposedly you can have the manufacturer of the drive reset this a total of 5 times (for a total of 25 region changes), but that just sounds like a PITA to even attempt. Of course you could always hack the firmware, but that can be dangerous and can lead to paperweights and replaced drives. There are also applications out there that I am aware of that can compensate for this sort of thing, but the only one I've ever tried is VLC (http://www.videolan.org/vlc/), and it didn't work entirely right on my powerbook or my XP MCE machine (sometimes it worked, sometimes it didn't). Also note that this particular gem was perpetrated upon us by the studios and the MPAA, so thank them for this.

Microsoft chose not to provide an MCE package that will work properly with Windows XP x64, but Windows Vista x64 does come with Media Center, so that may be something you are interested in. If you want to try 3rd party applications, I have heard that beyondtv and SageTV are working and are 64bit, although you'll have to make sure your hardware has proper x64 drivers, and there can be some codec issues when running in a true x64 media center solution. If you run Linux, you can always run MythTV 64bit, and I still rely on my TiVo, hacked and all - can't beat dedicated hardware.

Because newer versions of the msi.dll that contains the MSI function invariably break certain installers, and programs fail to install. Although this happens with almost all incremental msi updates, most people only install a new version of the msi engine when a new major version is released (1.0, 2.0, 3.0, 3.1, 4.0, etc), and these versions are better tested and supported by both Microsoft and third-party vendors that write .msi packages - meaning less impact on users and more stability in the engine. I think the ultimate factor in why this has not been released en-masse is that the problem, while an annoyance, is not necessarily a critical update to an actual broken, non-functioning component (things still work with the current non-patched version, for the most part, unless you leave your box up for weeks without rebooting after multiple patch installations). Therefore, the harm is quite possibly worse than the good the update brings, and vendors really only write .msi packages to the major versions. Ultimately, the bug isn't a major issue, it's an annoyance, and the possibilities to break things by releasing a fix for something that's not technically broken means the change will not be rolled out publicly - it'll simply be rolled into the next major msi engine release (4.0, with Vista).

You can use diskpart from the command line, or you can also use the resource kit utility mountvol (on 2000 and higher).

http://www.microsoft.com/technet/prodtechn...d/20_s3rem.mspx http://technet2.microsoft.com/WindowsServe...3.mspx?mfr=true http://download.microsoft.com/download/0/9...resentation.ppt http://smallbusiness.itworld.com/4380/nls_...731/page_1.html

On the new DCs, does the "policies" folder appear in SYSVOL, and is it populated with the same data as the original DC(s)? These errors are consistent with jrnl_wrap_error errors or "No network provider accepted the given network path" thrown by the FRS dealing with being unable to replicate some or all of the SYSVOL folder and it's contents. I'm not saying this is the case, but please check the SYSVOL folders on all your DCs and make sure they are identical, because the errors indicate that this may not be the case. You also need to run ntdsutil to make sure that your FSMO roles are all on valid DCs, and that none of the FSMO roles is still attached to the downed DC - these errors can also begin due to being unable to contact the PDCe.

Make sure that no one has placed an autorun.inf file in the root of that shared drive, which will change the behavior of the drive for clients in Windows Explorer. That'd be my first check - something on the server's drive changed if it is affecting all clients.

Correct me if I'm wrong, but I believe TrendMicro OfficeScan is an antivirus product.

You obviously haven't read the Unattended Guide linked right at the top of the forum pages: http://unattended.msfn.org/unattended.xp/view/web/38/

If you've got a Windows Server that you have access to, this can be done via RIS. It can also be configured via unattended install scripts started via WinPE before installation, or via scripts called from the GuiRunOnce section after installation. Have you visited the unattended site here on MSFN?

Ah, but pidgen.dll in the Windows 2003 source reads more than just the PID value in setupp.ini to determine retail vs. VLK vs. OEM - it reads the whole PID (not just the 270 vs 000), and it also reads the ExtraData field. There are ways to change the source (including this file) to make the source take a retail key and actually be a retail install, but that'd technically be in violation of the EULA. If your school really is an MSDNAA subscriber, you should've gotten a license key (downloadable from the MSDN subscription site) with that CD, and you wouldn't be having these problems.From the MSDNAA agreement: If you're in the CS program at your school, and your school is indeed an MSDNAA subscriber, you should've gotten a valid license key for that software. Assuming they acquired enough licenses, you're entitled to one if the work is under the guidance of your professor and is for academic research or CS coursework.

LOL

Yes - consider using those 802.1x policies. This would authenticate the machine against an IAS server (add/remove windows components on a 2000 or 2003 DC) on the domain, and would also authenticate the user via the same method (certificates and shared secrets - or smartcards, if you can swing it). This forces the wireless link to come up and send EAPOL packets back and forth with the IAS server before allowing logon - it'll slow the boot process some on wireless laptops on a domain, but it will both ensure the network is up before domain login, and also help secure communications between the wireless client and the domain and WAP (especially if teamed with IPSEC policies). Your WAP and/or switches also need to support 802.1x for this to work properly, but most do at this point. If they do, it's a viable, cheap, and easy solution to implement - with security benefits as well.

At this point, if you can access the shares on the MCE box from the server but not the client, I'd think there's not a firewall issue (if there was, you probably wouldn't have been able to get to the MCE box from the server, correct?). I'd say first disable the firewall on all client machines and see if the issue continues - this will at least either rule out the firewall or define it as the culprit. Assuming the issue occurs after disabling the firewalls, make sure all of the clients are configured with IP addresses on the same network subnet, with the same subnet mask, the same DNS and WINS servers (if configured), and the same default gateway. Once that's confirmed, get a network trace from both a client attempting to access a share on the MCE box, and a network trace from the MCE box itself (both traces run at the same time) - either via Ethereal/Wireshark or Netmon. Again, if it fails after disabling firewalls and configuring the network properly, the only sure-fire way to troubleshoot is to see what is happening across the wire (the fact that ping fails bothers me, especially if the firewalls are disabled - this would lead me to believe the network configuration is incorrect on one or more of the machines).

Whatever disk controller it's attached to is telling windows that the drive is removable - I'd check for newer drivers, and also log a support call or email to the chipset or motherboard vendor to see if they've heard of this before. Windows is just telling you what the hardware is divulging to it during hardware detection, so if it's showing as removable, then the removable (non-SCSI removable) bit is being set by the controller during the hardware probe for some reeason.

Have you run filemon or regmon (or both, from sysinternals) to see what is actually happening on the disk or in the registry while the slowness is occurring? I'd say it's definitely something other than Office causing the issue, if it's happening on multiple machines. I'd also suggest the standard troubleshooting - autoruns (from sysinternals as well) to disable all non-Microsoft startup items, services, and processes, and shellexview (from nirsoft.net) to disable all non-Microsoft explorer.exe shell hooks. Reboot, and see if the issue continues, and also run regmon and filemon during the time using Office to see if anything is hammering the file system or registry when the issue is occurring.