PiqueABoo

Just in time to start work on that upgrade to MCSE 2008 Which optional bits (besides Exchange) did you do?

This is really a FFS! but makes more sense here. A MSDN dotNet 2 reference talks about a 5 second interval and says "[X] will be lost", whereas the dotNet 3 version talks about a 6 second interval and says "[X] will be delayed". The difference between them will make or break any typical program using this bit of the APIs. The calls they are talking about live in the same DLL and that's exactly the same dotNet 2 DLL regardless of whether you have dotNet 2 or dotNet 3 installed (dotNet 3 essentially being dotNet 2 plus some new libraries). Maybe if 65535 people all hold hands and chant "It is a dotNet 3 DLL!" for long enough they'll move a few electrons and it it will work as documented in the dotNet3 description. Dunno.. Then I found someone who actually tested their code and accidentally proved the dotNet 2 take on the matter, which means a lot of smug example code on blogs and the like is broken.[1] -- And then you meet a incomprehensible MSDN description of some number you need to play with.. and all the code I found out there took it at face value.. that to derive Y from 32-bit number X you mask the top two bits.. when in fact X is definitely a 64-bit number and to get Y you mask the top 32 bits. [1] Reminds me of the 27 "expert" blogs and columns I found on getting started with 2K8 beta 3 Server Core with exactly the same, but absolutely broken netsh command line. I suppose they either stole or were handed the recipe by MS, despite clearly suggesting to us gullible readers that they had personally gone through and sweated over the process.

In recent years I've rarely seen a middle-of-the-range CPU get remotely near a bottleneck (unless cracking crypto or as the side-effect of a memory leak and paging). In fact the amount of time CPUs spend doing not much is one of the reasons for server consolidation on ESX servers etc. Getting top of the range CPUs will add a lot to the cost and not do that much compared to decent disks and sufficient RAM (I'd want 2GB RAM now and holes to add another 2GB without throwing any existing RAM away). I very much doubt it would be essential in the next 5 years, but 64-bit capable CPUs *might* be worthwhile e.g. some entry level Core 2 Duos don't support 64-bit. My old home box is a ~7yr-old dual P-III 700MHz and still runs XP and the apps I want very well (including a VM or two).

On DomainA you make a DNS stub zone for DomainB, and vice versa (Google for guides for creating a stub zone). If you're on a DomainA box and make a DNS request for something in DomainB, then the DomainA now has enough information to go to DomainB for the answer (should cache that), and vice versa. This is neater than forwarders, but if you did forwarders right (and if after clearing the respective caches could resolve say http://www.edugeek.net from boxes in both domains) and your trusts still didn't work then stub zones probably won't help either I'd go to a DC for DomainA and try an nslookup like this: nslookup >set type=all >_ldap._tcp.dc._msdcs. Where is fully qualified domain name for DomainB e.g. domainb.local. If that give a sensible answer[1], try the vice versa on a DC for DomainB. [1] Fully qualified domain names and IP addresses of DCs in the DomainB.

If it's 2K3 then stub zones have a bit more uh.. "finesse".

I started with a clean disk and briefly: 1) Installed Vista to a first partition, noting the disk signature. 2) Hid Vista partition with Ranish and installed XP to a second partition 3) Installed GAG boot manager (sadly XOSL had VESA problems with the box) 4) Ran XP first to put the disk signature back (so Vista would start) and made a third partition shared by both OSes. Both have C: for the system drive and Vista is in the best place for the future i.e. at the start of the disk.

When I were a lad ..remember a hour or two on a Saturday disassembling getadmin (source code was released later) and figuring the quick workaround for that with a US NT security wiz. MS did fix it. And later Paul Leach of MS, the informal i/f to the then NT security "community" (and former Apollo Nix guy if that helps) told us they had subsequently had a full, lengthy audit of the kernel done. SeDebugPrivilege was really another issue and ultimately being able to do anything with that is "by design" for good reasons. Anyway manifest errors can be lots of thing and the first screenshot looks like a genuine namespace problem i.e. something that can happen if you're not careful with those. I'm not an expert on trusting shares, but I'm not sure about the caspol line. I have a batch to remember the comand line I once needed and it looks like this: caspol.exe -m -ag 1.2 -url file://server/share/* FullTrust A not uncommon solution to trying to develop code on a locked down machine is to give them a VM environment and revert that to a nice clean snapshot when they've finished breaking it.

Intel -> Chances are the red message you get is "System Event Log full" and that will happen from rebooting it not-too-many times. You can boot it with a floppy to run the selview(?) util to review and clear the log. A few times I've seen the windows Intel Server Management Thingummy leak enough memory to kill the server in about 24 hours. To be fair that may have been a specific version, or because of problems with something else it relies on on the system - don't know, I decided it was much easier to stop caring and live without it.

That's the setting I was talking about from the registry perspective. Note the Community Solutions disclaimer though - that KB isn't quite the same as a normal MS KB.

Those work, but since it's 2K3 I would make stub zones.

Maybe it is.. I have got a problem where XP machines with IE7 get policy settings for the proxy. They're present in the user's ntuser.pol and other settings from the same policy are in HKCU. But when I look at the proxy reg value it is disabled and the proxy settings and exceptions values are not there. Reapply the policy (I just increment the GPO version, rather than run gpudate) and it's fine, so I reckon it's a first time the user runs IE7 issue. The only clue I've found.. and it might be worthless.. is that there is an HKLM value called "ProxySettingsPerUser" you didn't need for IE6 (which works fine with the same policy) but you might need to explicitly create and set to 1 for IE7.

"May well" is a bit strong.. recall I'm the one who once wrote and still uses an ARP scanner into which I embed the latest OUI (the IEEE company<->MAC list) every now and again. It might happen, but in practice I rarely see collisions between Vendorcorp's NICs and APs or whatever.

Well yes.. but we won't know that's really RM's fault without knowing more about the WUA on the image. Could be WUA was perfectly fine when they made an image, but it simply doesn't get along with a subsequently released WSUS server. Was it looking for something on your WSUS server to upgrade the client perhaps? Not that I'd especially tempted to stop and do the forensics once I'd got it working.

To get the latest, greatest WUA v3 (31st-Jul-2007) read here: msdn2.microsoft.com/en-us/library/aa387285.aspx And if that fixes a test box you might want to compare the versions of say "wuauclt.exe" with an unpatched RM box.

It is, but could be something as simple as which hotfixes have or haven't been pre-installed i.e. nothing especially Machiavellian or stupid on RM's part.

That would be my chief suspect, but Grommit said it's one of hundreds of NICs from a given vendor i.e. implies it's a workstation. If that nbtstat command doesn't do it (give you a Windows name which helps track it down) then rather than start unplugging things which hurts your fingers after a while, I'd telnet to switches and ask them what MACs they've got associated with which ports. Whether and how you can do that depends on your switches. For instance on an HP you can use this command: show mac-address IIRC there's another command you can feed a specific MAC which returns the port number (if any).

Ughh.. the DC with the PDC role is the default authoritative time-source for a domain. If it's 2K3 I get that syncing with an external NTP source e.g. change "ntp.example.com" to your favourite source and run these commands: w32tm /config /manualpeerlist:ntp.example.com /syncfromflags:MANUAL net stop w32time net start w32time w32tm /resync That's it, job done. You should have a nice informational event log event telling you it worked. Unless you've messed with them, the other DCs will automagically sync with the PDC. Unless you've messed with them, your XP workstations will automagically sync with the DC they picked at startup. Edit: I took this out of the above but it might save you some effort. If the w32tm command doesn't work you might need to substitute the version I need with an extra 0x8 parameter (depends on the remote NTP server): w32tm /config /manualpeerlist:ntp.example.com,0x8 /syncfromflags:MANUAL

The "Typical" install puts all the bits you need on one box i.e. MS expect that to be he norm. I've just done what will I really hope will be the last of a few E2K3+all-the-bells&whistles installs. E2K7 RTM is notoriously "feature incomplete", but SP1 plugs the holes and unless it is seriously broken hell will need to freeze over to persuade me to consider configuring an E2K3 again - it's just too damn fiddly, something I already knew, but E2K7 really emphasizes the point. A better dilemma for an install next year might be which OS do you install it on? Thought that was part of the job description, but if not then also pay close attention to AD replication and if you don't know how, learn how to trigger that manually and verify it happened. Exchange has suffered a bit since the divorce from it's own directory and failure to consider replication delays probably accounts for more hair loss than anything else.

GUI admin which is due in 2K7 SP1 for: a) bulk creation of mailboxes etc, b) pretty much everything to admin Public Folders. You can use powershell, CSV files etc. but that really hurts when you're accustomed to the ADUC extensions you get with E2K3. The trouble with this whole thread is that many of the opinions based on E2K3 are irrelevant for E2K7 e.g. reliability not really established, it does do disclaimers, it eats plenty of RAM (I'd take the MS figure for RAM (2GB plus 2MB - 5MB per mailbox) seriously. Note: You'll have to check into the justification, but I think MS suggest 8GB maximum for an "all-the-bits-on-one box" E2K7. Possibly just to persuade you to buy a second server licence etc., but I don't know.

Not saying it didn't happen for some unknown reason, but responses limited to devices on the same switch is not normal. ARP should work for any device with a working TCP/IP stack on the same subnet. [Wrote a win32 ARP scanner eons ago (spits out MACs, vendors, DNS etc.) and that has always received the expected responses]

Chicken ;b I'll conditionally surrender that point. The last few I've been near had things other then AD they needed (or worse, bits of AD they needed), but if it is mostly a "pure" DC then yes building it as new DC is less risky. I'd check what was going on with replication on the working DCs first though. If they were happily replicating from the broken DC then fine, otherwise you will lose any significant changes made to AD on the broken DC when replication wasn't working. And obviously there's some cleaning up to do afterwards (more if DC had the FSMOs).

I'd really like that to be true but I'm not convinced. Looking at Zimbra for instance, I get the impression you have to pay annually if you want to match the Exchange features. Am I imagining that? Someone from MS seems to have been an author on every other RFC since the late 90s so I'm genuinely interested. Which ones & how?

Pro: You don't have to wait around for someone else to make changes. Pro: You get all the things in the MS feature list. Obviously mail, but public calenders folders and delegation of right to mailboxes seem to be popluar e.g. so admin staff can clear the junk out of mailbox and/reply on behalf of Head etc. It gives everso important people with PDAs something to do with them. You can (don't have to) do things like connect with Outlook and PDAs from home. Con: If it's broke, you have to fix it. XCHG 2K3 is quite solid and tend to just chug along, but life can get difficult if it does break (steep learning curve, and quite a few things are best figured out before a potential disaster). Temporal Con: We're in in an awkward inbetween phase. E2K7 is out, but is missing some features you will want (SP1 has them, might be RTM'd early Nov). And because E2K7 is still relatively new there is nowhere near as much useful information to be Googled compared with E2K3. You also need to factor in X64 e.g. will that break anything else you want to put on the Exchange box?

Shouldn't you have restored c: drive + system state?

I would put MS Network Monitor 3.1 on the box and set it capturing immediately before running the client diag util. Then grope through the results to see exactly what it can't find, throw the URL in IE and see what that says.