Wrong. Someone does however need to explain why systems like this don't have SRP (Software Restriction Policies) or AppLocker Policies enabled with a ridged white listing rule set.
Servers/Drones/etc like these should NEVER allow any account permission to run non-whitelisted applications. The fact is, barely any code should be allowed to execute, and itâ(TM)s completely inexcusable for them to not be using the whitelisting rules that are part of Windows/Active Directory. In an environment like this where there are ridged policies for doing practically anything related to production software, preventing rogue code execution should be mind boggling easy for one moderately skilled administrator.
They are sold on DVD *today*, but not "yesterday". With apparently exception to Star Wreck I believe all of them were on IMDB well before they were anything more than web series. My bad for not explaining the context.
Of all I mentioned, only Doraleous and Associates is too new and has no physical release yet. I don't even know how much fame that show has yet (but yes, it completely deserves it).
I only knew of Star Wreck via torrent, I'd never heard of a physical release of that product back then. When it was released, I certainly had never heard of any of the people involved in it. Even if those folks are known now, I'm not sure how known they were before its release. (I don't care enough to check for this film.)
So IMDB has a clear tradition and quite likely violated it for...
Star Wreck: In the Pirkinning The Guild The Legend of Neil Dr. Horrible's Sing Along Blog
Frankly, if any web series also deserves to violate this rule, it's Doraleous and Associates. Awesome web based show that very easily deserves to be in IMDB, yet currently is not. Not unlike those other awesome shows which also avoided standard publishing paths. I know nothing about The Tunnel, but I think IMDB damn well should have a vetting process for things worth mentioning because they appear to already have one in spirit if not in their own law.
Anyway, these did not originate or target standard distribution channels, yet they got into the IMDB database. Was the only reason those shows got on IMDB is because some of the people working on or for them are well known, and IMDB actually has a flexible policy of supporting those who they like or are well known when clear traditions are broken? I don't think Star Wreck even had known actors, and yet it's original distribution channel was, *gasp*, torrent.
So yes, maybe the folks at The Tunnel kind of have a valid complaint, even if their show is as bad as parts of Star Wreck. Hell, it can't possibly be as bad as Neverending Story 3, which is listed on IMDB and most certainly should be forgotten by all who exist.
This has nothing to do with HDTV. Manufacturers saw the introduction of OLED over 5 years ago and knew right away that it was the end of life for LCD. They feared OLED because it’s introduction strongly indicated that all the research that went into LCD was a waste of money. They had very little incentive to put real research dollars into LCD from this point on, because they already knew, and had talked publically, about OLED being it’s replacement.
Given how well the manufacturing process for OLED has evolved in the past year, I’m pretty sure the end of life of LCD displays as an entire technology is less than a few years away. I’m sure it’ll have the same painful drawn out period where it costs more than LCD for no good reason other than to recapture research dollars before it becomes mainstream and completely kills LCD.
Lets just all hope that OLED becomes affordable in much less time than LCD did.
For Mac Deployment, I script the disk partitioning with the terminal version of diskutil, making the Windows partition the exact same size on all machines and have diskutil mark it as MS-DOS. I then use Bombich's OS-X compilation of NTFS-Progs v1 to capture and deploy both Windows 7 and Vista images to the Mac's while OS-X is in use. Students using the computers at the time don't even realize it's happening. NTFS-Progs v2 requires Darwin Ports; I don't believe anyone has made a truly native build of v2.
It's doesn't have multicast, but you can re-deploy Windows while students are using OS-X during a class. For me, students only may screw up a Windows push if they reboot a machine while I'm doing it. Then I start over. I can also do it all while netbooted SSH/ARD the commands for imaging to the machine. Never have to directly visit them.
NTFS-Progs is also open source.
Using my method though, you do have to use "dd" to capture and deploy the Windows boot sector located on what is my/dev/disk0 while the computer is either NetBooted or booted from a firewire drive. I also make my "MS-DOS" partition disk0s2 on a GPT disk while OS-X uses disk0s3. It's more important that the Windows partition be identical on all machines this way than the OS-X partition, so it's just easier to plan on it being the first available partition. The side effect is that if anyone launches bootcamp in OS-X as an administrator and tells it to get rid of the Windows partition, it actually will immediately get rid of the OS-X partition even if your booted from it. Doesn't affect me though, as I strip Bootcamp off my OS-X deployment image. Very few people could launch it even if I didn't.
The terminal version of diskutil I believe is in 10.4.7 and above. Though maybe it was released with 10.4.8.
So here you go. Far too much conceptual information about a process I suspect almost no one here knows beyond the few that already mentioned it. Enjoy.
So the best I can do is telling you how I do it for about 400 Mac's, and the tools I use. I basically use two OS-X 10.6 servers that host NetBoot images and Radmind, and then Apple Remote Desktop (ARD) on a client to control events occurring on all the clients be they booted locally or NetBooted.
I'll also be up front, if you are not computer savvy, and don't want to be, do not touch Radmind with the idea of using it to deploy anything beyond software to an already existing deployment. Stick with an image based package. If however you are computer savvy, can get around a command line, and need to support an unlimited number of *nix machines, especially in a lab, Radmind is an incredibly strong tool.
I solely use Radmind for both OS deployment and software updates because it's a delta based package and tripwire system which you don't need to rebuild over time unless an administrator makes horrible mistakes without a backup. If I really needed an image, I would have Radmind generate that build for me and then use 10.5/10.6's NetBoot/NetInstall creation tool on the results.
I do not use NetRestore, NetInstall, or any other deployment tools for OS-X. It is a waste of time to constantly rebuild and maintain various images over time vs a delta based deployment system, especially when I'm the only one supporting the image. It may take *slightly* longer to deploy than a sector based image, but the amount of effort placed on the administrator in the long term significantly decreases. Sure, learning Radmind might take a whole lot of time and effort, but the more random and variously configured machines you need to support are, the more attractive it becomes to spend time learning how to use it beyond a software package deployment tool. Heck, the right people behind it could probably support thousands of *nix servers without much of any effort.
You can also reverse the use of Radmind over time to maintain just software packages by making a negative transcript targeting just ".". If you do that, and make sure clients don't see the overall OS level packages, you can update software only without updating the OS at its core.
So radmind has a set of tools that come with it, and I'm only going to mention the most critical of them. One scans a computer for changes. Two other apps takes that scan and either uses it to upload data to a server, or to use the knowledge on the server to 'cause' changes to the client. Another downloads the command lists from the server, and those command lists have knowledge of all the "package" transcripts that actually define almost every file on the computer. Using them all in combination in scripts by someone that knows how to manipulate the results are what can make Radmind powerful.
Up front there are negatives and positives about Radmind: Negatives:
It can be very complicated.
A lot of the documentation is poor, though it's better today than when I started using it.
Simple mistakes in a transcript can suddenly prevent the client-side app from functioning. Discovering why can sometimes be very difficult. (especially if it's a nested command file level issue that only gives you "Input/Output error" when lapply crashes.)
It only supports network compression, which frankly is worthless. No file-based compression during capture.
Almost any error in a delta file will break process of updating/deploying machines. It really requires you have someone learn it in and out.
The default method of deploying images to massive numbers of machines that may need different builds is unwieldy. There are ways around some of this.
The GUI console in OS-X once you have several hundred transcripts is annoying to use, and creating and using subfolders for transcripts or command files will seriously screw your deployment life up.
I can't speak for the linux side of things, but here's my comments for Windows.
Note that while this is easier to manage with Group Policy via Active Directory, you can use the local group policy settings and migrate them across your lab. My thoughts on this are valid for XP and 2003.
The internal firewall is your first defense, blocking all non permitted inbound random/unimportant information from reaching your machines. Tell the firewall the applications you will be using, and it will dynamically open required ports as the program needs them. This way you don't need to deal with local port management. You want this setup to prevent traffic from reaching IPsec, and for any logging purposes you may have. IPsec's current version doesn't really do packet logging, and is in no way a firewall (Although, I used it for years as a firewall with Windows 2000 and never had any ill-received problems, but they were not on critical systems either).
Use IPsec in pure authentication mode without encryption (unless you have encryption offload cards). You can use it in several ways.
All communication requires authentication: No computer can talk to yours that is not setup properly. Period.
All inbound communication requires authentication: All inbound traffic must authenticate or be dropped.
If you lock inbound, but not outbound, your clients can still access web resources and any other computer without issue, but you have completely prevented anyone else from initiating communication with your systems.
IPsec works like this: Generic rules (require authentication from everyone) are over-ridden by a more explicit rule (do not require authentication from whatever.system.local). Generic all IP rules are over-ridden by port rules, port rules are over-ridden by explicit IP address rules or subnet rules. Etc.
For your purpose, I would at least require all inbound traffic to require authentication by String, however this is not secure and anyone with administrator access can rip the password out of the registry. To do it securely, you need to do it by certificate or Kerberos. The kerberos implementation will require active directory, the certificate method will require a full IKE/PKI configured for your area. You do not need to buy a certificate from a place like verisign, you can do it all yourself through your own self-signed certificates. This entire process with IPsec can be automated through Active Directory, but if you don't have active directory, I believe any generic IKE/PKI server can generate valid certificates for your use. It's a lot less work on your part doing it through active directory.
IPsec policies will work between Windows 2000, XP, and 2003, however your key strength is limited based on the oldest OS you use. 2000 will only function with low keys, XP with both low and medium, and 2003 with strong keys and the two weaker keys. Also, you can set it up from strongest key generation to weakest, so 2003 will always talk to 2003 in strong, 2003 to XP in medium, 2003 to 2000 in weak. It may be possible to make IPsec work side-by-side with Linux using Freeswan, or whatever project replaced it, however I never used that program.
One last thing, if your systems are used by untrusted users, considers how possible it is to use the software restrictions built into Windows. Once that is activated and configured well, it becomes very difficult for a local user to run non-authorized software without sitting at the machine and taking it over first. Refer to rules regarding Software Restriction Policies for this.
While I agree that Microsoft really shouldn't have most users as Administrator by default, it's also in large the fault of the programmers that develop software for Windows that make Microsoft decide to keep it that way..
I work in a computer lab and try hard to lock everything on the drive down before letting students have at it. Ever try running MusicMatch (any version) without being administrator? I could only get version 5 to do it, and that took a serious amount of hacking to it's registry settings + hex editing one of it's data files, even then the program could only play music, not rip or burn. Photoshop 6.0? Worked but had issues. Almost all the pre-Macromedia MX software had issues and didn't quite function properly if you were not an administrator with full rights to the program files directory. Premiere 6 wouldn't even function if a user didn't have full rights to one preference file in the Adobe folder, and if they delete that file the program won't work because it can't recreate it (Delete inhibit works yes, but Premiere is one of those programs that suffers from constant preference corruption). After Effects up to version 5.0 required full rights to a folder in program files. All current AVID software is a great example of software not written properly to be used unless you're an Administrator, and as they've been trying to push themselves into education I have no idea why they haven't fixed this problem since version 2.5 of AVID DV. Games requiring Administrator rights for anything unless you've got program files locked down is also beyond me. Only a few companies actually make their games properly as to not require Administrator rights, and I'm pretty sure it's companies own laziness and not Microsoft when some games like Quake and Unreal not only don't need administrator access, they can survive an OS reinstall and being moved between drives or computers without failing.
Hardware insecurity causes burning software to require administrator access *or* the software alters a few policy security settings (Roxio doesn't even tell you it's doing it, where Nero requires a separate tool to even activate non-administrator burning) allowing direct access to the SCSI/IDE chain, allowing arbitrary commands used just right to bypass Windows security and do small things like read files they shouldn't have access to or to just wipe out the file table. I believe this is more Intel's fault than Microsoft's, though from the way's I've heard the issue described by Nero, but I could be wrong.
So while you can blame Microsoft for trying to keep compatibility with current software and for leaving stupid things on by default (file sharing/NetBIOS) and not having on the built in firewall on XP/2003 Server it is also the fault of programmers who write for Windows who can't figure out how to use the system designated user folders instead of their own random place on your drive. All of Adobe & Macromedia's software is finally working properly at most recent versions as a restricted user (though Macromedia Dreamweaver MX at least requires DLL launching access from user directories, blah).
Blame does live in Microsoft though when it comes to holes during installation. Unless you take time to learn how to script your own install and inject hot fixes manually into the CD, there is absolutely no way you can install XP/2003 on a machine while on a large LAN without risking someone or a virus breaking in through a hole that should not have been there at all before I choose to open that service. I was pretty amazed when I saw that 2003 Server didn't have netBIOS/IP sharing off and firewall on by default when that would have saved XP pre-sp1 (and now pre-sp2 with the recent RPC holes) from being taken over. Especially for a non-home targeted product, that was just backwards thinking.
Slashdot Mirror
Wrong. Someone does however need to explain why systems like this don't have SRP (Software Restriction Policies) or AppLocker Policies enabled with a ridged white listing rule set.
Servers/Drones/etc like these should NEVER allow any account permission to run non-whitelisted applications. The fact is, barely any code should be allowed to execute, and itâ(TM)s completely inexcusable for them to not be using the whitelisting rules that are part of Windows/Active Directory. In an environment like this where there are ridged policies for doing practically anything related to production software, preventing rogue code execution should be mind boggling easy for one moderately skilled administrator.
They are sold on DVD *today*, but not "yesterday". With apparently exception to Star Wreck I believe all of them were on IMDB well before they were anything more than web series. My bad for not explaining the context.
Of all I mentioned, only Doraleous and Associates is too new and has no physical release yet. I don't even know how much fame that show has yet (but yes, it completely deserves it).
I only knew of Star Wreck via torrent, I'd never heard of a physical release of that product back then. When it was released, I certainly had never heard of any of the people involved in it. Even if those folks are known now, I'm not sure how known they were before its release. (I don't care enough to check for this film.)
I forgot Troops! The Star Wars / Cops parody! This is also on IMDB and was web only.
So IMDB has a clear tradition and quite likely violated it for...
Star Wreck: In the Pirkinning
The Guild
The Legend of Neil
Dr. Horrible's Sing Along Blog
Frankly, if any web series also deserves to violate this rule, it's Doraleous and Associates. Awesome web based show that very easily deserves to be in IMDB, yet currently is not. Not unlike those other awesome shows which also avoided standard publishing paths. I know nothing about The Tunnel, but I think IMDB damn well should have a vetting process for things worth mentioning because they appear to already have one in spirit if not in their own law.
Anyway, these did not originate or target standard distribution channels, yet they got into the IMDB database. Was the only reason those shows got on IMDB is because some of the people working on or for them are well known, and IMDB actually has a flexible policy of supporting those who they like or are well known when clear traditions are broken? I don't think Star Wreck even had known actors, and yet it's original distribution channel was, *gasp*, torrent.
So yes, maybe the folks at The Tunnel kind of have a valid complaint, even if their show is as bad as parts of Star Wreck. Hell, it can't possibly be as bad as Neverending Story 3, which is listed on IMDB and most certainly should be forgotten by all who exist.
This has nothing to do with HDTV. Manufacturers saw the introduction of OLED over 5 years ago and knew right away that it was the end of life for LCD. They feared OLED because it’s introduction strongly indicated that all the research that went into LCD was a waste of money. They had very little incentive to put real research dollars into LCD from this point on, because they already knew, and had talked publically, about OLED being it’s replacement.
Given how well the manufacturing process for OLED has evolved in the past year, I’m pretty sure the end of life of LCD displays as an entire technology is less than a few years away. I’m sure it’ll have the same painful drawn out period where it costs more than LCD for no good reason other than to recapture research dollars before it becomes mainstream and completely kills LCD.
Lets just all hope that OLED becomes affordable in much less time than LCD did.
For Mac Deployment, I script the disk partitioning with the terminal version of diskutil, making the Windows partition the exact same size on all machines and have diskutil mark it as MS-DOS. I then use Bombich's OS-X compilation of NTFS-Progs v1 to capture and deploy both Windows 7 and Vista images to the Mac's while OS-X is in use. Students using the computers at the time don't even realize it's happening. NTFS-Progs v2 requires Darwin Ports; I don't believe anyone has made a truly native build of v2.
It's doesn't have multicast, but you can re-deploy Windows while students are using OS-X during a class. For me, students only may screw up a Windows push if they reboot a machine while I'm doing it. Then I start over. I can also do it all while netbooted SSH/ARD the commands for imaging to the machine. Never have to directly visit them.
NTFS-Progs is also open source.
Using my method though, you do have to use "dd" to capture and deploy the Windows boot sector located on what is my /dev/disk0 while the computer is either NetBooted or booted from a firewire drive. I also make my "MS-DOS" partition disk0s2 on a GPT disk while OS-X uses disk0s3. It's more important that the Windows partition be identical on all machines this way than the OS-X partition, so it's just easier to plan on it being the first available partition. The side effect is that if anyone launches bootcamp in OS-X as an administrator and tells it to get rid of the Windows partition, it actually will immediately get rid of the OS-X partition even if your booted from it. Doesn't affect me though, as I strip Bootcamp off my OS-X deployment image. Very few people could launch it even if I didn't.
The terminal version of diskutil I believe is in 10.4.7 and above. Though maybe it was released with 10.4.8.
So here you go. Far too much conceptual information about a process I suspect almost no one here knows beyond the few that already mentioned it. Enjoy.
So the best I can do is telling you how I do it for about 400 Mac's, and the tools I use. I basically use two OS-X 10.6 servers that host NetBoot images and Radmind, and then Apple Remote Desktop (ARD) on a client to control events occurring on all the clients be they booted locally or NetBooted.
I'll also be up front, if you are not computer savvy, and don't want to be, do not touch Radmind with the idea of using it to deploy anything beyond software to an already existing deployment. Stick with an image based package. If however you are computer savvy, can get around a command line, and need to support an unlimited number of *nix machines, especially in a lab, Radmind is an incredibly strong tool.
I solely use Radmind for both OS deployment and software updates because it's a delta based package and tripwire system which you don't need to rebuild over time unless an administrator makes horrible mistakes without a backup. If I really needed an image, I would have Radmind generate that build for me and then use 10.5/10.6's NetBoot/NetInstall creation tool on the results.
I do not use NetRestore, NetInstall, or any other deployment tools for OS-X. It is a waste of time to constantly rebuild and maintain various images over time vs a delta based deployment system, especially when I'm the only one supporting the image. It may take *slightly* longer to deploy than a sector based image, but the amount of effort placed on the administrator in the long term significantly decreases. Sure, learning Radmind might take a whole lot of time and effort, but the more random and variously configured machines you need to support are, the more attractive it becomes to spend time learning how to use it beyond a software package deployment tool. Heck, the right people behind it could probably support thousands of *nix servers without much of any effort.
You can also reverse the use of Radmind over time to maintain just software packages by making a negative transcript targeting just ".". If you do that, and make sure clients don't see the overall OS level packages, you can update software only without updating the OS at its core.
So radmind has a set of tools that come with it, and I'm only going to mention the most critical of them. One scans a computer for changes. Two other apps takes that scan and either uses it to upload data to a server, or to use the knowledge on the server to 'cause' changes to the client. Another downloads the command lists from the server, and those command lists have knowledge of all the "package" transcripts that actually define almost every file on the computer. Using them all in combination in scripts by someone that knows how to manipulate the results are what can make Radmind powerful.
Up front there are negatives and positives about Radmind:
Negatives:
It can be very complicated.
A lot of the documentation is poor, though it's better today than when I started using it.
Simple mistakes in a transcript can suddenly prevent the client-side app from functioning. Discovering why can sometimes be very difficult. (especially if it's a nested command file level issue that only gives you "Input/Output error" when lapply crashes.)
It only supports network compression, which frankly is worthless. No file-based compression during capture.
Almost any error in a delta file will break process of updating/deploying machines. It really requires you have someone learn it in and out.
The default method of deploying images to massive numbers of machines that may need different builds is unwieldy. There are ways around some of this.
The GUI console in OS-X once you have several hundred transcripts is annoying to use, and creating and using subfolders for transcripts or command files will seriously screw your deployment life up.
It has no GUI on anything except OS
I can't speak for the linux side of things, but here's my comments for Windows.
Note that while this is easier to manage with Group Policy via Active Directory, you can use the local group policy settings and migrate them across your lab. My thoughts on this are valid for XP and 2003.
The internal firewall is your first defense, blocking all non permitted inbound random/unimportant information from reaching your machines. Tell the firewall the applications you will be using, and it will dynamically open required ports as the program needs them. This way you don't need to deal with local port management. You want this setup to prevent traffic from reaching IPsec, and for any logging purposes you may have. IPsec's current version doesn't really do packet logging, and is in no way a firewall (Although, I used it for years as a firewall with Windows 2000 and never had any ill-received problems, but they were not on critical systems either).
Use IPsec in pure authentication mode without encryption (unless you have encryption offload cards). You can use it in several ways.
All communication requires authentication:
No computer can talk to yours that is not setup properly. Period.
All inbound communication requires authentication:
All inbound traffic must authenticate or be dropped.
If you lock inbound, but not outbound, your clients can still access web resources and any other computer without issue, but you have completely prevented anyone else from initiating communication with your systems.
IPsec works like this: Generic rules (require authentication from everyone) are over-ridden by a more explicit rule (do not require authentication from whatever.system.local). Generic all IP rules are over-ridden by port rules, port rules are over-ridden by explicit IP address rules or subnet rules. Etc.
For your purpose, I would at least require all inbound traffic to require authentication by String, however this is not secure and anyone with administrator access can rip the password out of the registry. To do it securely, you need to do it by certificate or Kerberos. The kerberos implementation will require active directory, the certificate method will require a full IKE/PKI configured for your area. You do not need to buy a certificate from a place like verisign, you can do it all yourself through your own self-signed certificates. This entire process with IPsec can be automated through Active Directory, but if you don't have active directory, I believe any generic IKE/PKI server can generate valid certificates for your use. It's a lot less work on your part doing it through active directory.
IPsec policies will work between Windows 2000, XP, and 2003, however your key strength is limited based on the oldest OS you use. 2000 will only function with low keys, XP with both low and medium, and 2003 with strong keys and the two weaker keys. Also, you can set it up from strongest key generation to weakest, so 2003 will always talk to 2003 in strong, 2003 to XP in medium, 2003 to 2000 in weak. It may be possible to make IPsec work side-by-side with Linux using Freeswan, or whatever project replaced it, however I never used that program.
One last thing, if your systems are used by untrusted users, considers how possible it is to use the software restrictions built into Windows. Once that is activated and configured well, it becomes very difficult for a local user to run non-authorized software without sitting at the machine and taking it over first. Refer to rules regarding Software Restriction Policies for this.
K.
While I agree that Microsoft really shouldn't have most users as Administrator by default, it's also in large the fault of the programmers that develop software for Windows that make Microsoft decide to keep it that way..
I work in a computer lab and try hard to lock everything on the drive down before letting students have at it. Ever try running MusicMatch (any version) without being administrator? I could only get version 5 to do it, and that took a serious amount of hacking to it's registry settings + hex editing one of it's data files, even then the program could only play music, not rip or burn. Photoshop 6.0? Worked but had issues. Almost all the pre-Macromedia MX software had issues and didn't quite function properly if you were not an administrator with full rights to the program files directory. Premiere 6 wouldn't even function if a user didn't have full rights to one preference file in the Adobe folder, and if they delete that file the program won't work because it can't recreate it (Delete inhibit works yes, but Premiere is one of those programs that suffers from constant preference corruption). After Effects up to version 5.0 required full rights to a folder in program files. All current AVID software is a great example of software not written properly to be used unless you're an Administrator, and as they've been trying to push themselves into education I have no idea why they haven't fixed this problem since version 2.5 of AVID DV. Games requiring Administrator rights for anything unless you've got program files locked down is also beyond me. Only a few companies actually make their games properly as to not require Administrator rights, and I'm pretty sure it's companies own laziness and not Microsoft when some games like Quake and Unreal not only don't need administrator access, they can survive an OS reinstall and being moved between drives or computers without failing.
Hardware insecurity causes burning software to require administrator access *or* the software alters a few policy security settings (Roxio doesn't even tell you it's doing it, where Nero requires a separate tool to even activate non-administrator burning) allowing direct access to the SCSI/IDE chain, allowing arbitrary commands used just right to bypass Windows security and do small things like read files they shouldn't have access to or to just wipe out the file table. I believe this is more Intel's fault than Microsoft's, though from the way's I've heard the issue described by Nero, but I could be wrong.
So while you can blame Microsoft for trying to keep compatibility with current software and for leaving stupid things on by default (file sharing/NetBIOS) and not having on the built in firewall on XP/2003 Server it is also the fault of programmers who write for Windows who can't figure out how to use the system designated user folders instead of their own random place on your drive. All of Adobe & Macromedia's software is finally working properly at most recent versions as a restricted user (though Macromedia Dreamweaver MX at least requires DLL launching access from user directories, blah).
Blame does live in Microsoft though when it comes to holes during installation. Unless you take time to learn how to script your own install and inject hot fixes manually into the CD, there is absolutely no way you can install XP/2003 on a machine while on a large LAN without risking someone or a virus breaking in through a hole that should not have been there at all before I choose to open that service. I was pretty amazed when I saw that 2003 Server didn't have netBIOS/IP sharing off and firewall on by default when that would have saved XP pre-sp1 (and now pre-sp2 with the recent RPC holes) from being taken over. Especially for a non-home targeted product, that was just backwards thinking.
K.