clutch

Quote: Just a silly point, but wouldn't Half-Life squared actually be Quarter-Life?? I'm looking forward to this game. Only someone with "No-Life" would recognize this...

Um, yeah. All of your clients and member servers need to be resolved via DNS in order for them to be serviced. That is in AD 101. Now, a cheat for that is to have DNS perform WINS and WINS-R lookups. Say a client can't register itself in DNS, but it does successfully register itself with WINS. DNS can be setup to query the WINS db for the hostname, resolve it from WINS, and then tack on the remaining TLD naming info. For example, you have a Win98 box that can't register in DDNS, but it shows up fine in WINS. A Windows 2000 client pings win98.yourdomain.com and the W2K DDNS box can't find that name in its DDNS zone. It will then subtract the ".yourdomain.com" from it, query WINS for "win98", get the IP, and then return ".yourdomain.com" to the name and resolve the IP. This is what I used to do with NT domains while setting up NT DNS. Enabling both WINS and WINS-R (Reverse) lookups will let you perform forward and reverse lookups (reverse lookups aren't typically mandated in AD, but proper Kerberos configurations require it). I am not sure how your VPN works, but are you pointing the clients to the internal DDNS servers when they come on? Is there any way that you can reserve an IP for a specific client, and then manually enter that client name into DDNS for AD? If you can do that, you can then see if it's a resolution issue.

Get an Xbox and save your money!!!

When running in realtime mode with multiple CPUs, I doubt you are tying up all the resources of all of them, therefore you are leaving some available for the OS. Again, running anything in Realtime mode is a poor idea. Run it with a higher priority? Sure, but not Realtime.

Quote: Just seems that the Intel setup I have isn't happy with capturing video in HT mode... ...or rather, your software isn't happy with H/T. I would say it's the latter.

Quote: I have noted that with H/T enabled, IF I run SETI 3.x character mode as a REALTIME CPU priority priveleged application? I occasionally get "jams"/hangups... Blah, blah, blah... Running anything in "Realtime" mode is a poor idea, as all the cpu cycles (effectively) get handed to the application, and thus you get hops and skips when the OS or other apps need attention. If the app cannot field all these resources properly (and most don't, for various reasons) the OS can collapse around it. HT is more of a cheat at multi-processing. Rather than being a true SMP box, this CPU can spit requests as needed and run the independently(ish). I would imagine that a lot of apps out there cannot fully take advantage of it yet, but expect patches to update them. HT is a great way to go if you can, you just might have to wait to get all the support you want/need.

When you set it up before, were you using AppleTalk or SAMBA? If you are using SAMBA now, it could be what is giving you issues. The newest OS from Apple has (or will have soon) an integrated AD client added to its LDAP support which should make all of this seemless. In addition, the schema mods will not be necessary unless you are looking to manage the Macs via Group Policy in your AD environment. I guess what I don't understand is what your ultimate goal is. Are you looking to create a directory on the server, manage it from the server, and then allow for write only (to protect doc confidentiality between the clients)? If so, the SAMBA client should allow for this if NTFS permissions are set on the directory, as the share can have whatever it wants listed, but the server will only give back what is permitted. This should address the limitations of the client. I am not sure at what level you were applying your previous Write Only permissions. I don't have the Mac anymore to test this, but the AD client seemed fine (we were beta testing it) with resolving this, and SAMBA in Linux performed similarly.

It's OK. I like VMWare better, but VPC is available for the Mac and it's free with my MSDN subscription, so it's what I'll be using soon.

Check out my response here: http://www.ntcompatible.com/forums/viewtopic.php?t=14233&highlight=slow+network+browsing Might want to give searching a try next time, as this comes up quite a bit.

Quote: AS, We have not implemented DFS yet. We are looking into it, but that wouldn't happen till we were in native mode sometime in May. I have a meeting with others next week to look at group policies. After reading the article Clutch mentioned and looking at a totally default AD setup I found we have some strange policies set. Supposedly the NT admin folks used the same policies set in NT 4.0, but even if that's true something is still wacky!! Thanks for all the help. I will let everyone know what happens next week. Policy translation is a huge issue. I am an engineer working on a migration strategy for the Army from NT4 to 2003, and right now we are ironing out the policy setups. There are so many options that people seem to feel the need to configure all of them. We have seen most of the proposed configurations trash the lab, and now we are going to design one from the current production baseline (a small fielding of Windows 2000 AD to about 2000 users) and translating it for Windows 2003. If you need a good product for policy lifecycle management, you should check out NetIQ's Group Policy Administrator. It has a simulator that looks for many common configuration flaws, has a vault for checking in/out templates, can deploy to a test lab before production, spans multiple domains and AD environments, and so on. Version 4 is due out soon, and we are waiting for the RTM from Full Armor to make it through NetIQ to us.

I had to dig up the command, but have the user try: set logonserver from the command prompt. It should return what DC he/she is connecting to. If the issue is occurring with the same DC, then you might have a weak link in your AD.

One of your DCs could be having difficulties replicating with the others. The intermittent failure would then come from people hitting the failing DC, which bombs out. When they try again, they might contact one of the others and get properly logged on. Check the logs and see if replication is occurring (NTFRS) between all of the controllers before you delete the machine accounts. It could be that the VPN solution is on a segment that is favoring one particular DC, and that one is not replicating properly. Also, make sure that the NETLOGON service is running on all of the DCs. The machine might be passing the existing cached credentials on the laptop to the Exchange server, and thus able to be validated. Other areas of concern could be misconfiguration of Group Policies. Here's a good article on things to avoid: http://support.microsoft.com/default.aspx?scid=kb;en-us;823659

I haven't seen any reliable way to have multiple machines hooked up to the same disk. Even SANs have this issue, as you really need one virtual disk "presented" to one machine at a time. The machine can, in turn, share out this disk just like any other disk and have it available over the network. This seems to stem from the way the OS handles writes to the disk. When we were testing out SAN setups with Compaq hardware, we could have several machines linked to the same virtual disk. However, when one systems would write a file to the disk, the other machines could not read it. So if SERVERA, SERVERB, and SERVERC were all connected at the same time to the disk, they would only see what was there at the time they were initially setup for the disk and what they wrote themselves (i.e., if there was a text file on there when the disk was first setup to SERVERA, it would see that and every file that SERVERA ever writes to it, but not what SERVERB and SERVERC wrote to it). This was unfortunate, as we were looking to move disk images from all of the servers to the same virtual disk for backup via fibre, but wound up have a single system with the disk mounted and sharing it over the network to all the others. If all of the systems that were mounted to the disk could receive updates when one wrote to it (kinda like in clustering with the heartbeat cable and quorum using a SAN or shared-bus SCSI config) then this would work out pretty well. However, I don't think there's anything right now that would let you do this with consumer-grade hardware.

Strange, I have 2 firewire/USB2 enclosures that are daisy-chained already. On top of that, I hook up my iPod 40GB to the second enclosure, and sync across the whole chain. I am doing all of this with my SB Audigy panel interface's firewire port. What would the bridgeboard offer that I am not doing already? I was under the impression that the standard allowed for daisy-chaining, and the only differences were whether or not you had powered ports and cables to pass juice (4 or 6 pin).

Try to resolve the errors on the clients if possible utilizing that link, and it might address the server. Also, did you use any policies with registry key limitations? The policies that worked fine in Windows 2000 do not necessarily work in Windows Server 2003 due to the SERVICE account being split into "LOCAL SERVICE" and "NETWORK SERVICE". Also, the "LOCAL SERVICE" account now holds many permissions in the registry that the "SERVICE" account never needed in Windows 2000. Review the DC policy and see if there are any registry keys (like winreg) that have limited permissions applied. Just because you have disabled portions of it, this might not clear all of it (yeah, GPs are wierd that way, that's why we always have clean backups for our labs). Also, this may be obvious, but is the "SYSVOL" share coming up?

Quote: Just a thought. Make sure remote registry service is running via services tab. i ran into similar issue trying to anage IIS with remote reg disabled. That can also happen if the existing policy had permissions assigned to the winreg registry key, and there was no provision for the new "LOCAL SERVICE" account in Windows Server 2003. However, this will typically not affect replication, but will affect service and general system management (both local and remote).

Is it the only DC on the network? If so, it could be that the server is not authenticating in time to start services properly. You also checked the reg keys mentioned here? http://support.microsoft.com/default.aspx?scid=kb;en-us;314494

I am assuming that you have more than one domain controller, and are merely joining a new DC to an existing 2003 AD. If that's the case, try setting the new DC's (the one with the connection issues) DNS entries (in TCP/IP properties) to point to the existing DDNS server in your AD. Make sure that the only entry in the properties is for the existing DC, and not for any other DNS servers. Next, either flush the DNS cache (ipconfig /flushdns) or reboot the affected server. It should now request all DNS name resolution from the established DC. If this corrects the issues, then the new system has a misconfigured DDNS service (or the entire AD DNS setup is having issues, and might have corrupt/incorrect SRV entries). Let me know what happens when you get this far.

It is on all of our test servers, and none of them have iTunes. Apparently, many applications are using GEAR Software's API in their applications: http://www.gearsoftware.com/cfknowledgebase/articledisplay.cfm?articleid=52. and GEAR is hearing about shutdown delays (amongst other issues, I imagine) on their forums: http://www.gearsoftware.com/gearmegaboard/detail.cfm?threadparentid=682&boardid=4 They might have updated drivers to fix this, but I have not had the time nor inclination to check (I just disable it on the servers, and my XP box hasn't had much of an issue using iTunes).

When you get the error, try killing and restarting explorer.exe and see if it frees it up. Explorer could be hanging on thumbnail generation or some other aspect of file management, and thus claiming a sharing violation when you try to work with it.

I am hoping they don't screw up V2i, but it is Symancrap afterall...

Gearsec comes on all Windows Server 2003 boxes now, and I am pretty sure it has started showing up on XP as well. When we started testing 2003 en masse, we would get occasional errors about gearsec not starting. The application belongs to some company (I Googled it few months ago checking it out) and it appears the MS is licensing it for their OSs now.

Quote: The second option would be getting a free linux distribution. I guess all support usb , there are some that can be run without an insatllation. Only a bootable cd is needed. However many applications used with MP3 players only work in Windows, and most of those will not work properly within WINE or other similar methods.

Some vendors tried getting USB ports to show up as SCSI connections (such as Iomega with their Zip drives) but for the most part they are useless. One unit that comes to mind is the Rio Karma. This unit has an ethernet port on it which will let you "taxi" files back and forth using a Java-based version of Rio Music Manager. You can find out more at www.riovolution.com and checking out the forums.

That sucks. The use of templates for regkey and file permissions management is rarely used, and with good reason. For those people that have been using NSA-based templates in 2000 and migrating to 2003, you will appreciate what I mean. The "SERVICE" account in 2000 has been broken up into a couple accounts, and these restrictive policies with NTFS permissions have broken things such as the winreg key access and the like in new installs of 2003. In addition, if a regkey was modified by someone and then a template was reapplied, the key permissions will *not* be adjusted unless the template specifies that key in particular with permissions. In other words, like most template functions that are left "Not Defined" in a policy manual changes will not be changed nor reset. A complete tear down is the best way to address this. In the future, using image-based backup applications (like PowerQuest V2i or Ghost) is the best way to assure system integrity with immediate restoration.