To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please mail to firstname.lastname@example.org.
This was a busy month, between speaking to crowds in Toronto at Comdex Canada, attending a one-on-one briefing with Microsoft on XP, and learning a bit about XML. But the big lesson of the month was hearing from a lot of you that your Active Directory migrations are happening slooooowly. I kind of knew that but hadn't heard how many people were doing mixed mode migrations. So this month, the Tech Section looks at a migration issue that I'll bet you've never even considered -- mixing up NT, Wintendo, and 2000 policies. I'll also pass along a few comments on RC1 of XP Pro, both good and bad.
As you may know, I'm doing several talks at the Fall's Comdex in Vegas -- as are many other speakers. But I was pleased and surprised to see that Comdex's home page www.comdex.com features Mastering Windows 2000 Server! If you're going to be in Vegas then please consider joining me. (More on conference appearances later in this newsletter.)
I note from the returned mail that some people's mail servers have a ridiculously small maximum size limit on accepted mail -- around 25K to 30K. Most of these newsletters run in that range, so it got me wondering: what about offering an option whereby I just send you a super-short piece of mail that basically just says, "hey, the latest newsletter is at so-and-so URL, come read it on-line?" You'd click the link to read the newsletter, which would be sitting on my Web server, and my Web server would request your name and password, then show you the newsletter in your browser.
The idea wouldn't be to force everyone to use the URL. Instead, it would just be a third option: right now, you can choose to receive the newsletter either in its full text via email in ASCII text format, or you can choose to receive the newsletter in its full text via email in HTML format. This would be a third option -- to receive only a short e-mail announcing the URL. And there wouldn't be a new account to create, as you all already have such an account. When you signed up for the newsletter, you gave me an e-mail address and chose a password. That's what the system would use.
I'd have to build some scripts so it wouldn't be immediate and I don't even know if there's interest. If you'd like such an option then drop me a line at email@example.com. Thanks!
As I said last month, we've closed the book on public seminars for 2001 as I need time for the Fourth Edition (a combination of 2000 Server and .NET Server coverage).
But that's it for public classes in 2001; no more until 2002. The reason? I need to keep my time open for the Fourth Edition, which I'm starting work on now. It'll cover both Windows 2000 Server and Windows .NET Server. (And in case you've not been following your geek gossip, that is the new name of what we might call NT 5.1 -- that is, the next version of Server. MS originally said it was called Server 2002, but changed their minds -- the latest name is Windows .NET Server. As .NET Server isn't that big a change, it'll be simple to cover both in the same edition, and it gives me a chance to further expand and improve the book.
So Raleigh, Dallas, DC, New York, Pasadena, San Francisco, and Chicago are the last seven publics for this year. I'm still scheduling in-house seminars through the end of the year as time permits.
Our two-day Windows 2000 seminars have been a lot of fun and the attendees have been great. Built atop the Third Edition, we add coverage of things even more up-to-date than the Third; I've already added coverage of Windows .NET Server enhancements, a big section on troubleshooting group policies and some major enhancements to the Active Directory replication info, stuff too new to have made it into the Third -- and there's more coming. Visit www.minasi.com/pubsems.htm to see specific session dates and locations, seminar outline, and how to sign up.
Dallas and Raleigh are NEXT WEEK, so if you've been thinking about signing up, now's the time.
As you probably know, on October 25 Microsoft will ship "NT 5.1 Workstation" under the name "Windows XP Professional" and "Windows XP Home." I got a chance to see the Release Candidate 1 in early July. I was surprised to see that it added a few new features -- RCs often just contain polishing-up and bug fixes. I haven't got room to cover all of XP here, but let me tell you about what I saw as the most interesting new RC1 feature: "NAT traversal." Using something called "universal plug and play," the NAT traversal tries to solve the problem of "how do I communicate from inside one NAT network to another?"
More specifically: suppose you've got a cable modem or DSL connection with a connection sharing device of some kind, like a DSL router. The DSL router has two IP addresses. First, there's the honest-to-God, fully routable IP address that it got from your Internet provider, connected to the DSL or cable modem connection. Then there's the connection to a hub that you've got all of your internal machines connected to -- the old Windows 9x boxes, NT machines, 2000 systems, Macintoshes, or whatever. The DSL router's job is to share the one "legal" Internet address among several devices. But every device needs a unique IP address. Lots of devices, but just one IP address -- what to do?
As you may know, DSL routers solve this problem by giving all of the internal systems -- those Windows, NT, 2000, and Mac machines -- IP addresses from a block of addresses set aside to be "non-routable." Anyone can use them. There are several blocks, but most DSL routers seem to use the 192.168.1.x or 192.168.0.x subnets. The DSL routers then use something called network address translation or, more correctly, port address translation to share the one routable address with all of the internal systems. How it does it is pretty simple: whenever an internal system wants to access the Internet, perhaps to browse some Web site, then that system just says to the DSL router, "please forward this request to Internet address so-an-so," as routers normally do. But the DSL router knows perfectly well that it CAN'T do that: if it says to the Internet, "hey, someone at 192.168.1.3 has a request," then the first Internet router to see the message will simply refuse to route it, as the address is in a range of addresses that are, by definition, NON-routable. So the DSL router DOESN'T say "192.168.1.3 wants something;" instead, the DSL router substitutes ITS routable address. Then, when the answer to 192.168.1.3's question comes back, the DSL router remembers which machine asked the question in the first place, and routes the answer to 192.168.1.3. The result is that to the general Internet, that DSL router sure seems like a demanding system, when in fact it is simply busy because it is "impersonating" a bunch of systems.
In any case, notice that it's possible for an internal system (one with one of those 192.168.x.x addresses) to initiate a communication with a device on the public, routable Internet, but it's NOT possible for a device on the public, routable Internet to initiate a conversation with an internal 192.168.x.x system.
Here, then, is the problem. Let's suppose I'm sitting at a 2000 Pro box in my home that has a 192.168.x.x address, accessing the Internet via my DSL router or cable modem sharing device. You're sitting in YOUR house, also using some kind of DSL router or cable modem sharing device to access the Internet. We meet on-line and decide to play some networkable game, and start to set up our connection. One of us acts as the server and one as the client. The client then initiates communication with the server. That's where the problem appears. I could initiate a communication to a routable address, or YOU could initiate a communication to a routable address, but neither of us has a routable address... and so we can't communicate.
(Note that some of you might be scratching your heads saying, "Mark, I don't have that problem." In that case, I'm guessing that you use your Windows 98 SE, Windows ME, or 2000-based system as the DSL or cable modem sharing device. As you know if you read chapter 6 of Mastering Windows 2000 Server, you can easily activate something called Internet Connection Sharing to make your 98 SE/ME/2000 device into a simple NAT router. But if you do your gaming while sitting at that box, then NAT isn't a problem, as that particular computer has a legal IP address, recall, as IT'S the device connected to the Internet.)
How, then, to create a meeting of the minds in PC-land? With NAT traversal. The idea is that if your DSL router (or other sharing device), your opponent's sharing device, and your game software understand NAT traversal then the two sharing devices work out the details to allow 192.168.x.x-to-192.168.x.x comms with no muss, fuss, or greasy aftertaste. And XP Pro's version of Internet Connection Sharing supports NAT traversal, so if you replaced your DSL router with an XP Pro (or Home) box, then you'd have all the more on-line gaming options. (And of course it's good for more than just gaming; you could use this for any peer-to-peer communications that must go through a NAT-type router, like Webcam-type videoconferencing -- once there's videoconferencing software that understands NAT traversal.)
That was some of the good news; that bad news which I won't belabor (but read my columns for Windows 2000 Magazine Update at http://www.win2000mag.net/email/index.cfm?Action=Archive&EmailNewsLetterID=1 if you've not heard of it; request the 25 May and 27 April columns), save to say that Microsoft is clearly not budging on this one. If you buy a retail copy of XP Pro or Home, you'll have to put up with Microsoft's routine that inventories your hardware and reports on-line to Microsoft about whether or not you're sharing your copy of XP Pro. I surely wish they wouldn't do this, but it seems a fait accompli and is sufficiently obnoxious that I suspect that many people will choose not to upgrade at all. (At least, not at first.)
I have mentioned in the past that I'm acting as series editor for a bunch of books that various authors are preparing for Sybex. The books all focus on Windows 2000/.NET Server topics. One of those books is a Group Policy book authored by Jeremy Moskowitz called Windows 2000: Group Policy, Profiles, and IntelliMirror. It's not out yet but should be in a month or so. (You can preorder it at http://www.amazon.com/exec/obidos/ASIN/0782128815/qid%3D995425114/markminasi/104-2944187-3530362.) But I'm not here to sell you the book; rather, I wanted to tell you about something interesting that came out of reading the book and intrigued me to look further.
Jeremy's the lead author, but he got a lot of help from a fellow named Derek Melber. Derek is a techie teacher from the Phoenix area and he put together an appendix that looked at every possible combination of system and group policies in a mixed environment. Consider this question, for example: suppose you were sitting at a Windows 2000 Professional workstation which was a member of an NT 4.0 domain. You, however, have a user account in an Active Directory domain. The machine's NT 4.0 domain contains system policies. Your user account's AD domain has group policies. Which policies take effect? Which policies have precedence over others? Derek did a ton of research to get the answers, looking at every combination of workstation type (Windows 9x/ME, NT 4.0, Win2K) versus the type of domain that the user's account is in (NT 4.0 domain or Active Directory) versus the type of domain that the machine account is in (again, NT 4.0 domain versus Active Directory). He got some interesting results. In this article, I'll relate them to you and extract some basic rules for understanding the behavior of policies in a mixed environment.
This is all a bit techie and gets kind of involved -- but trust me, once you're in a multi-OS environment, you'll run into this stuff. It's worth knowing.
We'd like to simplify user's desktops and, sometimes, restrict what they can do to lower the cost of keeping those desktops running. To help do that, Windows 95 introduced the idea of a "system policy;" Windows 98, Windows ME and NT 4.0 all basically follow the same model. System policies work by letting you, the administrator, remotely modify the Registries of your workstations, flipping switches in the Registry that restrict the things on the user's desktop. For example, some of those settings will remove the Control Panel, limit the programs that the workstation will run, or simply tell the workstation to reset its configuration every time the user logs off. Many of those Registry keys have existed for years, but it's a pain to visit every workstation to change them.
Instead of making you wear out your shoes walking around editing user's Registries, system policies came along. They allow an administrator to put a file of desired Registry changes on a central location, the Netlogon share on NT domain controllers. System policies work because part of the code in an NT 4.0 or Windows 9x workstation knows to retrieve that file and obey its commands. Windows 9x/ME ("Wintendo," as I think of them -- mere toy operating systems!) use a slightly different policy file format than NT 4.0, so a shop using both Windows 9x and NT desktops would need two policy files -- CONFIG.POL for the Windows 9x systems, and NTCONFIG.POL for the NT systems. You create the POL files with a program called POLEDIT.EXE. Basically, then, system policies work like this: the user logs onto the domain. As part of the domain logon, the workstation requests either CONFIG.POL or NTCONFIG.POL from the Netlogon share of whatever domain controller logs it on. (Actually, Windows 95 has a bug where by default it always tries to get CONFIG.POL from the PDC, but the other workstation OSes are smarter and use whichever DC logged them on.) The workstation then applies the desired changes to the Registry, whether they're user settings or machine settings. The user will then see the effects of those Registry changes the next time that the relevant portions of the Registry are read. For example, if a system policy changes a user's wallpaper, then the user will see those changes immediately, as the workstation accesses the "what wallpaper would I like?" key in the Registry as part of the logon process. But if a system policy changed something like a setting on Personal Web Server, then that Registry entry wouldn't be read until the next time that Web Server started up. That would probably be the next time that the workstation booted, although if someone stopped and started the Web Server service that would trigger the policy's effects as well.
Group policies are a bit more complex, but here's the short version. First of all, they're not just one discrete file, but instead pieces of data -- "objects" -- in the Active Directory, in combination with files stored in the Active Directory domain controller's Sysvol shares . Second, they can do far more than just modify the Registry to control what users do with their workstations. Group Policies are instead a bit more subtle. Basically they're a set of instructions to a bunch of DLLs running on 2000 Pro and Server boxes. For example, one of those DLLs, USERENV.DLL, has the ability to accept commands that essentially change the Registry, which is how group policies manage to duplicate everything that system policies can do. But group policies go beyond the things that system policies did; for example, Microsoft has made group policies the main vehicle for controlling software deployment and modifying security settings. Where you'd modify a user right like the ability to log on locally at User Manager for Domains under NT, you'd have to use a group policy to modify the ability to log on locally. Or, in another example, consider IPSEC, a tool that lets you define a secure and encrypted IP link between two or more systems: you'll notice that there's no "IPSEC Manager" in your menus. Instead, you control IPSEC solely through group policies. Furthermore, group policies are not just read when the user logs on. Instead, workstations and servers retrieve their domain's group policies upon startup, and then periodically throughout the day. Users' group policies are retrieved at logon time, as well as periodically throughout the day.
As not everyone has a domain, you can directly place group policies on a given Windows 2000 workstation or server. Notice that this ISN'T a centralized control system, but rather a local administrative tool. (You can, however, use tools to create these local group policies from another system.) There are, then, two kinds of group policies: "local group policies," which are created and stored on a local system, which effect control of a system whether you have a domain or not, and "domain group policies," which reside in the Active Directory and which are retrieved and applied at system startup, user logon, and periodically throughout the day.
In short, administrators in a purely NT 4.0 domain would use system policies to effect a certain amount of remote control over its workstations and servers. They would do that by creating an NTCONFIG.POL file with POLEDIT and storing copies of it in all of the Netlogon shares on all of the domain's domain controllers. Administrators in a purely Windows 2000/Active Directory domain would use domain group policies to effect a greater degree of control on the domain's workstations and servers. They would do that by creating "Group Policy Objects" with the Group Policy Editor. People running a network that included Windows 2000 systems but that didn't have a domain could effect some control of their systems by visiting each system either in person or over the network and creating local group policies for those machines.
Now let's see how a network with a variety of workstation types would respond to a mix of system and group policies. I've tried to boil down the "policy retrieval and execution" behavior to a few rules. If this is inaccurate, it's my fault, not Jeremy's or Derek's: I found myself interested by their text, so I went ahead and did my own experiments. Here's what I found.
1) Older Systems Don't Know About New Policy Types: policies are enforced by CLIENT-SIDE code. Therefore, a workstation running an older OS cannot in general use policies stored on a domain controller running a NEWER OS, as it doesn't know to look for them. Example: NT won't even know to ask about any existing group policies, as group policies didn't exist in 1996 when NT was released. Newer OSes can, however, in general read and understand older policies: for example, 2000-based systems can use NT 4.0-type system policies when there aren't any group policies available.
More specifically, policies only work because the OSes are hardwired to request them and obey them:
I covered this in the Mastering Windows NT Server book, but relatively few NT admins used system policies, so I suspect that a lot of people just skimmed the system policy part, and so this isn't commonly known, so let me underscore it with an example. Suppose we've got an NT 4.0 enterprise with two domains -- one named USERS, which contains the user accounts, and one named MACHINES, which contains the machine's domain accounts. We've built a two-way trust relationship between USERS and MACHINES. (In case you're wondering, there isn't usually a reason to separate user and machine accounts this way -- I'm just suggesting this for the sake of example.) My user name is MARK and my machine's name is MARKSPC. When my system powers up, it logs onto the MACHINES domain, but does not retrieve an NTCONFIG.POL from MACHINES. When I sit down at the machine and log in as MARK from USERS, then my machine knows that part of what it's supposed to do when logging me on is to go to the Netlogon share for the USERS domain and download the NTCONFIG.POL file from that domain. It will contain both machine and user policies. Yes, it IS a bit strange when you think about it; you'd think that you'd build the policies that control the machines in the MACHINES domain in the MACHINES domain and store it in the Netlogon shares for the MACHINES domain controllers. But you don't -- it's just another reason to upgrade to Windows 2000.
And, to reiterate, Windows 9x, ME, and NT only download system policies (CONFIG.POL or NTCONFIG.POL) at the time that a user logs on -- a user logon is the only event that triggers a policy retrieval from a domain controller.
3) How Windows 2000 Systems Handle Policies: in contrast to the previous rule, Windows 2000 client machines download and obey both policies from the user domain AND the machine domain, no matter whether those domains are NT domains or AD domains. Additionally, Windows 2000 machines don't just download policies when a user logs in, but instead ask the user and machine domains for the latest policies regularly throughout the day.
Despite the fact that a 2000 workstation gets a set of policies from the domain where the machine has its account and another set of policies from the domain where the user has his account, the workstation doesn't use the ENTIRETY of each of those policy sets. Iinstead, the workstation only pays attention to the machine policies that it gets from the machine account's domain, and the user policies that it gets from the user account's domain. If a domain offers a Windows 2000 client both group policies and system policies, then the Windows 2000 client will ignore the system policies and use only the domain group policies. If the domain only has system policies (i.e., it's an NT 4.0 domain), then the 2000 workstation will download and execute those system policies.
2000 workstations (and servers) download and execute policies more often than at user logon time. Machines download machine policies from their domains -- assuming that the machine has an account in an Active Directory domain -- at startup. Then they download them again all throughout the day -- about every 90 minutes for a workstation or member server, and every five minutes for a domain controller. Further, machines download user policies when a user logs on, and then re-download them roughly every 90 minutes (workstation/member server) or five minutes (domain controller).
4) Handling System Policy and Local Group Policy Conflicts: recall that 2000 boxes can have a kind of group policies called LOCAL group policies even if they're not a member of an Active Directory domain. If faced with both system policies from an NT 4.0 domain and local group policies, the local group policies override system policies. If a 2000 workstation receives a system policy that says to require (for example) a minimum length of nine characters for passwords, but the workstation also has a local group policy that only calls for six characters, then the workstation will only require that new passwords have six characters. If a system policy and a local group policy conflict, the local group policy wins.
When would a 2000 workstation see an NT-type NTCONFIG.POL system
policy? When the workstation's machine account lives in an NT 4.0 domain,
or when a user with an account in an NT 4.0 domain logs onto that workstation.
But remember that any Windows 2000 machine can have LOCAL group policies,
whether it's a member of an Active Directory domain, a member of an NT 4.0
domain, or just a simple workgroup member. So it's entirely likely that
any 2000 system that receives an NTCONFIG.POL would also have some local group
policies. (Of course, no Windows 9x, ME or NT computers get local group
5) Handling Domain Group Policy to Local Group Policy Conflicts: domain-based group policies override local group policies. This makes sense, as you wouldn't want a local administrator (who can set local group policies) to create a policy that overrode a domain-wide group policy.
Let's apply these rules to see the results of various scenarios.
There are 10 possible mixed-policy scenarios.
First, there's the question of what operating system the workstation runs. (Or server, for that matter, but let's assume for the moment that the machine receiving and executing policies is a workstation.) It could be running Windows 9x/ME, Windows NT 4.0, or Windows 2000 -- three possibilities.
Second, recall that we might have a machine with an account in one domain but a user with an account in another domain. So the next question is "what sort of domain is the machine a member of -- an NT 4.0 domain, or an Active Directory domain?" Note that an NT 4.0 workstation could be a member of an Active Directory domain (so its machine account would then exist in an AD domain, not an NT 4.0 domain), or a Windows 2000 Professional workstation could be a member of an NT 4.0 domain.
Third, the account of the user logging in could either exist in an NT 4.0 or an Active Directory domain.
Three workstation OS options, two machine domain types, and two user domain types gives us 12 possible scenarios initially. But remember that Windows 9x/ME systems do not have machine accounts, so we've got only ten scenarios:
Workstation OS User Domain Machine Domain
W9x NT N/A
NT NT NT
NT NT AD
NT AD AD
NT AD NT
2K NT NT
2K NT AD
2K AD AD
2K AD NT
Here are the results for the ten scenarios, with explanation.
Rule 2 says that Windows downloads a policy file (CONFIG.POL) from the Netlogon share of a domain controller in the USER's domain. Nice and simple and in fact that's the original scenario for system policies: Wintendo on the desktop, user logging onto an NT domain. Rule 1 explains why Windows 9x wouldn't use group policies, and the desktop would ignore any NT system policies -- it'd never even know to download NTCONFIG.POL.
Same situation. The administrator places a standard Windows 9x-type CONFIG.POL into the Netlogon share of the Active Directory DC. The only real difference is that in general AD only uses Netlogon to service the pre-2000 boxes. In contrast, NT relies upon Netlogon.
Again, a classic scenario. Remember from Rule 2 that even though the workstation might have its machine account in a different domain that the workstation won't ever interrogate that domain for policies; instead, it gets all of its policies from the NTCONFIG.POL file sitting in the Netlogon on a domain controller in the user's domain. (The DC that authenticates the user, obviously.) Rule 1 explains that NT doesn't know about the newer Windows 2000, so it doesn't request group policy information. Of course, there are no local group policies on an NT machine.
Now we introduce some AD, but it has no effect because, again, of Rule 2. NT just plain isn't programmed to ask its machine domain for policies (Rule 2) and doesn't know about group policies (Rule 1) so it would have no reason to ask its domain for policy info. As it's an NT workstation, once again there are no local group policies.
Rule 2 says we're getting policies from the user's domain, but Rule 1 says that NT only looks for NTCONFIG.POL. It looks for it on the Netlogon on the DC in the user's domain (an Active Directory domain) that logged the user on. Again, no queries to the machine's domain for policies. No local group policies as it's NT.
Same as the previous because of Rule 2 -- when it comes to policies on NT, only the user domain counts.
Now we start looking at how Windows 2000 clients behave upon logon. Remember that 2K systems have something new in addition to policies that they get from a domain -- they've also got local group policies.
Rule 3 says that the workstation seeks policies from both the machine and user domains. Both domains are NT domains, so the workstation gets two NTCONFIG.POLs. It ignores the user policies in the NTCONFIG.POL from the machine domain, and ignores the machine policies in the NTCONFIG.POL from the user domain. Rule 4 says that the workstation then applies any local group policies, which would override any conflicting NTCONFIG.POL-type policies.
By Rule 3, the workstation asks the user domain for policies, but only user policies. The user domain turns out to be an NT 4.0 domain, so the workstation gets the NTCONFIG.POL from the domain and executes the user policies in that file, ignoring any machine policies. By Rule 4, the workstation applies any local group policies that are user policies, and those policies would override any policies that the workstation got from the NTCONFIG.POL. Then the workstation would interrogate the machine domain for machine policies and discover that the domain is an Active Directory domain, so it gets the domain group policies, ignoring any NTCONFIG.POL on the AD domain controller. T(he workstation only looks at the domain group policies with machine policies, of course.) Rule 5 says that domain group policies override any local group policies, so in the event of a conflict the policies from the domain would win.
By Rule 3, the workstation asks the user domain for user policies, ignoring its machine policies, and asks the machine domain for machine policies, ignoring its user policies. As the user domain is an Active Directory domain, the workstation gets domain group policies. Rule 5 says that those domain group policies override local group policies, recall, so in the event of a conflict, the domain-based group policies would win.
The machine policies, on the other hand, come from an NTCONFIG.POL from the machine domain, as that domain is an NT 4.0 domain. Rule 4 says that the workstation will apply those policies, but that any conflicts with the workstation's local group policies are decided in the local group policies' favor.
The classic Windows 2000 Active Directory scenario: the workstation has local group policies that it applies, then it gets domain group policies for machine issues from the machine domain and user-related domain group policies from the user domain. Domain local policies override any local group policies.
Before I leave this topic, one final note about mixed mode domains: the Netlogon shares on Windows 2000 domain controllers don't replicate to one another.
Under NT 4.0, you could set up the Directory Replication service to ensure that any changes to NTCONFIG.POL on the PDC would be automatically reflected on all of the BDCs. Windows 2000 doesn't have the Directory Replication service; instead, it has a better directory replication service called FRS, the File Replication Service. Anything in any DC's Sysvol -- the directory on a Windows 2000 Active Directory domain controller that contains files like default profiles and logon scripts -- gets automatically replicated to every other DC's Sysvol.
Now, Windows 2000 maintains a Netlogon for backward compatibility's sake, and all of the Netlogons on the Windows 2000-based domain controllers replicate to one another. But in a mixed-mode domain, then some DCs may be running NT 4.0. If you've set up the old NT 4.0 directory replicator service, then the NT 4.0 BDCs' Netlogons will replicate to one another. (An NT 4.0 DC has a Netlogon, but doesn't have the File Replication Service; it's only got the directory replicator service, and that's only if you've set it up.) So the Windows 2000 DCs will replicate Netlogons amongst themselves, and the NT 4.0 Netlogons will replicate amongst themselves, but the NT 4.0 Netlogons will not replicate to the Win2K Netlogons, and vice versa. So if you're running mixed mode and there's important stuff in your Netlogon shares, then you'll have to cook up a batch file to copy files from one Netlogon to another, and then set up the Schedule service to run that batch file periodically.
Whew! That was a lot to slog through, and I hope that I explained it clearly. If not, drop me a line.
I hope you'll join me for a seminar but if you can't attend a class then please consider attending one of these conferences:
HP World has asked me to do two talks at their upcoming Chicago conference -- an all-day talk on Active Directory design and migration, and an half-day talk on Intellimirror (group policy, software rollouts and the like). Info at http://www.hpworld.com/.
Another reliably good show, and one gaining in popularity, as it seems that every one that I attend is larger than the one before. It's got great sessions and is back in San Francisco. Info at www.techmentorevents.com.
The same folks that put on that Windows 2000/Exchange 2000 Connections conference in Monterey are coming to Phoenix (well, really Scottsdale) in early October. I get to keynote, as well as do my Active Directory overview, an explanation of what Windows XP and 2002 will do for (or to) you, and then I debut my "12 Things You Can Do To Secure Your Windows 2000 Network" talk. Find out more at www.winconnections.com.
Yes, it's crowded, insane, and messy... but Fall Comdex is too much fun to pass up. For the third year running, George Spalding hosts Comdex's Windows 2000/2002/XP "X-treme Knowledge" (God, I can't wait for that "X-treme" stuff to die out) sessions. Sign up and you'll hear not just George and me but also my co-authors Christa Anderson and Doug Toombs. I'm not only doing my 2000/2002 talks, I've also been asked to do my Software Conspiracy talk: "Why Software Firms Produce Faulty Products, How They Can Harm You, And What You Can Do About It." The site with the specifics on the program is at http://www.key3media.com/comdex/fall2001/education/extreme/.
I'm keeping busy doing Windows 2000/.NET Server seminars, but I've still got time to visit your firm. In just two days, I'll make your current NT techies into 2000/2002 techies. To join the large pharmaceutical, agricultural, aerospace, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at www.minasi.com/w2koutln.htm, mail Jennifer Williams at firstname.lastname@example.org, or call her at (757) 426-1431 (between 1 and 5 Eastern time, weekdays, please).
Have a great month! Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000/.NET Server/XP information. Please forward it to any associates who might find it helpful, and accept my thanks. We are now at over fourteen thousand subscribers and I hope to use this to get information to every single Mastering NT and 2000 Server reader. Thanks for letting me visit with you, and take care -- may we all weather this current industry slowdown in peace! Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews. As always, I'm at email@example.com.
To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do NOT reply to this mail; for comments, please mail to firstname.lastname@example.org.
All contents copyright 2001 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.