cluberti

Note that a vast majority of folks using this specific drive model score 3.0 maximum, across a whole host of systems, so I doubt the controller is the root cause. Unless they're all using a ICH9R/G33's, which would be quite coincidental .

Look, the tests you post are testing sequential read speeds with burst rate, and drive seek time (not actual time to do anything once the seek is done). They don't test any caching, random read and write, or anything else that would stress the firmware. Those tests are cosmetic at best - they mean nothing compared to the Winsat tests, which go deeper in testing the cache performance, read and write random speed on multiple size files, rather than just how fast the seek is or how fast you can sequentially stream a file (which should be fast on almost any drive). Again, I respectfully disagree - your testing methods are not thorough for accurately testing drive performance. They're a part of what a drive can do, but definitely not something that would take into account any of the above methods Winsat performs. Also note that you have older drives that are slower at these superficial tests that perform better - meaning they likely have better firmware and can handle the odd loads that the real world would give them better. I would seriously recommend opening an administrative command prompt and run winsat disk -v on both old and new disks, and see exactly where the discrepancy is. It's not random, I assure you - those older disks really are doing better at the winsat tests than the Seagate 500s. For example, I have a 250GB WD SATAII drive that scores a 5.5, and a winsat disk -v run shows this: C:\Windows\system32>winsat disk -v Windows System Assessment Tool ... > Disk Sequential 64.0 Read 51.89 MB/s 5.4 > Disk Random 16.0 Read 1.39 MB/s 3.4 > Average Read Time with Sequential Writes 11.715 ms 2.9 > Latency: 95th Percentile 36.290 ms 2.5 > Latency: Maximum 89.616 ms 7.7 > Average Read Time with Random Writes 13.741 ms 2.8 > Total Run Time 00:00:50.87

Check your PM.

IE8 indeed does not delete cookies or any other cache specifically associated with a favorite. If you are seeing the cookies get deleted, then you are either deleting all browsing history with the "preserve favorites website data" option unchecked, or you have a bug (or the cookie is expired, in which case it will get deleted the next time the garbage collector goes into your TIF to find expired data to delete, but this would happen regardless of if you deleted manually or not).

No offense, but there are a number of other people with just this particular drive also scoring 3.0 on the tests, and they're failing due to the fact that the drive controller is just woefully inefficient once the drive is under load. It's good that you filed a bug, but it's a problem with the drive firmware, not Winsat - hopefully Seagate will fix it, but don't count on it (their track record for fixing drive build problems seems to be "ignore it, and it'll go away" lately, so.......).

btw, that host is basically a content delivery network from Limelight used by MS - so it's a normal host network to see WSUS or WU connecting to for update synch.

There is one way that can "bridge the gap", and that is to use MDT to stage both your Vista and XP installs. Obviously the XP installs will be images or flat file installs, depending on which way the wind blows in your environment, but it provides one WinPE environment for all images, and allows XP to be fully automated (and can be moved into SCCM if need be if you use it later) thus reducing the potential for screwing up. It also does a really good job of hardware discovery and driver installs, so that's a plus. And with Vista being image-based, you'd have everything come off the same WDS server or farm, use the same WinPE boot from PXE, USB, CD, whatever, and it'll at least allow for the exact same install every time for a flat-file XP install if that's the way you do it this week.

Agreed - it seems as if Windows thinks you have multiple monitors attached, meaning the video driver is likely telling Windows that you have 2 monitors. If you can remove one of the two cards and it works, this is likely the reason. I also have seen issues with certain ASUS boards and multiple PCI-E video cards that require a BIOS update before this works in Win7 (finding non-existant monitors, marking the wrong card as the primary, etc).

Assuming W2K was installed before XP, they should work (I just did this in a VM). If it's complaining about the registry when booting W2K (and it is), a repair install of 2K should potentially fix it, although not sure what it'll do to your boot.ini.

I would suggest a support case with Microsoft, because I don't know how else you'd do it. Windows file sharing was never meant to deny access this way, only to have permission-based access. Also, Novell does this differently (mapping permissions into a buffer to handle the ABE) vs how Windows does it (ACL check, disk hit per ABE lookup), so it's inferior in that way as well (although it does work on larger volumes better due to the Novell buffer design). In general, on Windows, you would map a share to the farthest point down the tree a user would use, rather than a root folder like that.

The last time MSFN upgraded IPB was done on October 3rd of this past year.

You might want to do it soon - free support cases for XP will end on April 14th of this year.

Without ABE, this is not possible. At least not with what ships with Windows - there may be something third party, but I do not know of anything off the top of my head.

Well, short of being an a**, telling them that they should have checked the licensing before thinking this was feasible would've saved them some heartache. Even if you can do it, it's against the EULA: You could add additional 2003 servers to be DCs if you want, - but the FSMO roles are stuck on the SBS server (and you can't add a second SBS server, you could only add a Standard/Enterprise/Datacenter server). And, of course, you can't add another Exchange, SQL, ISA, Sharepoint, etc server into the environment without removing the SBS server from the domain. There does appear to be a gray area where you could buy an additional Exchange server, SQL server, etc and buy the full license for those and not be under the SBS splitting the single license that comes with SBS, but at that point you don't really need SBS anymore, so...

Talking about a warez'ed version of Windows *and* being snarky? Banned. Good riddance. And for those thinking we don't apply the warez rules to beta OSes, take this as a warning. If you did NOT get Windows directly from Microsoft, a licensed partner or OEM, or a legit store selling the packaged product, it's warez. Period. Discuss it here and you *will* be banned. It's my new-year's resolution.

You could consider using some sort of VM underneath the SBS 2003 server, but that platform was designed specifically not to work with any sort of techniques for failover or recovery (other than making backups), because that functionality requires 2003 Ent or higher. I think VMWare offers VM redundancy/clustering in their ESX product, but it doesn't support atomic writes to the virtual disk (so it's not 100% HA/failover), and it requires a SAN. Honestly, it'd be cheaper to migrate to non-SBS servers at that point anyway.

Because that's the way that FF and IE7 decided to implement the spec.

If you're getting a win32 crash (is it always in firefox?), it could be a video driver issue, it could be a problem with the application itself sending the GDI information down to Windows, etc - hard to say without something more than a minidump to look at. I would suggest configuring for a complete memory dump, and then uploading that .dmp file somewhere the next time the problem occurs.

If you're not averse to using a USB key or some other method, autopatcher might be your easiest bet.

Again, be careful how you word it. There is actually no *wrong* way to display the CSS that applies to the spans that are created for CODE and CODEBOX objects on the forum. The CSS specs basically say that *either* way is fine, and both conform 100% to the CSS spec. This is why saying that a browser is "standards compliant" is a misnomer - you can implement a spec one way, have it be ugly, and still be standards compliant. As to the ads, I'm sure if there was a larger userbase for Opera the Vibrant folks would spend the time to make it work .

Which of course I could "revert" asking you on what sites/forums you think using IE7 IE, any version, is a good idea? jaclaz It's a well-known CSS layout issue, and it's not IE specific (for those of you who heap coals on IE, rightly or wrongly, should not do so in this case). Since the section of the CSS on table layout in this specific area isn't exactly documented on how to properly do the overflow, IE does it.... well, the layout is bad. Note, however, that Firefox (at least 3.0.6) also does *exactly* this, so it's not "wrong", it's just ugly. And unfortunately, it's perfectly within the CSS 2 spec - we won't go into whether or not it should be done one way over another, because it's obvious which is better - but, unfortunately, being spec compliant isn't enough, because the **** specs aren't very clear. Anyway, it repros with IE8, Google Chrome, Safari, and FF 3.1.x too, so this is just a case where IE and FF handle a CSS element in a way Opera does not. So because Opera decided to implement the CSS spec differently than IE *and* pretty much every other browser than Opera, does that mean that using "FF3, FF, any version, is a good idea?" I can be snarky too.

If this is a local folder that is not accessible over the network, I would suggest SYSTEM account also have access. However, if this is accessible over the network, and you don't store any Windows-needed or service-needed files here, removing SYSTEM should not be ultimately harmful.

From what you're saying, I would think that the root of the problem (other than not allowing auth users perms on the share - not sure how that worked at all in the first place, but what you've done there is the recommendation I would have made) is actually replication between your DCs. Replmon is your next step, because missing policies means either someone is deleting them (not likely) or they're not being pushed out properly (more likely), which may *ultimately* lead back to a DNS problem (again, given the symptoms, I think this will ultimately fall back on DNS). Find the replication issues, and you may unearth DNS problems. Good luck.

Power cycling a system and the NIC still doesn't work.... did I read that right? If it takes an actual hard power reset, then I would claim faulty hardware for sure.

Question - is the software published or assigned? Also, enabling userenv logging might be quite beneficial as well.