Over the past few days I've had the opportunity to test Windows Server 2008 in my environment. I'm looking at placing it on my primary file servers, as they're due up for replacement/migration/cleanup. So, I opted to write out some of the more interesting features I've noticed, those especially emphasizing benefit to our network.
Distributed File SharesThink symbolic links. Instead of mounting a \\server\share\folder\folder\folder, instead, you mount a \\namespace\folder. This, however, does not work with MacOS clients right out of the box. Doing some research, you can download some apps that will allow you to mount a virtual DFS share, but to load an application to every single Mac on our campus is too much of a pain in th ass. So, essentially, DFS goes off of the priority list.
File QuotasWindows Server 2003 maintained file quotas per user per partition. So, if Guy A was a member of five AD groups that have access to 15 folders, he could save up to the quota limit--regardless of where he saved them. The owner of the file was also important: If Guy B creates a file and gives it to Guy A, to which he places it on the file server--the file counts against Guy B. In essence, the file quota system sucked.
However, in Server 2008, this has been rectified, which was one of the primary reasons I wanted to wait for 2k8. File Quotas can now be managed multiple ways: Per folder, user/AD Group, or share. (I'm not entirely sure if the AD Group portion is true, to which I'll double check tomorrow. ) So, if I have Department A, Department B, and Department C, with the three departments sharing members, I no longer have to worry about who is saving what to which folder. Fantastic.
TCP/IP PrintingToday was also an experiment on network printing. Our Lead Tech spent several months putting into place an easy-to-use networkable printer system. Well, let me clarify that: It's easy to use if you understand how networks work. You know, DNS translation and DHCP. In short, I give a website a MAC Address and a hostname, the website feeds both to a DHCP scope, and viola'. When you plug the printer in, it has the IP Address. Configure the queue to the network information, and you're in. Now it's simpler. Sort of.
Server 2008 will automatically detect any printer on the network based on hostname or IP address. Put it online, done. The website he designed won't change much, but now detection is drastically simpler: It knows what model printer it is and loads the necessary driver.
IIS 7.0Another change was IIS. Since I'm not a web programmer, nor did I have any websites to port over to the test environment, I don't have a proper evaluation for it. However, from the new features (comparing 6.0 to 7.0), I did like some of the newer authentication procedures.
Read Only Domain ControllersThis is something I'd love to implement strictly because it's new. Unfortunately, we don't have a need for it. Basically, you have a domain controller that has only has the capability to read active directory--it cannot change a thing. This is perfect for offsite locations outside of the primary IT center, somewhere that doesn't have the constant security an Operations room would(might/should) have.
Access Enumeration ListsThis one was slick. One of Microsoft's "mottos" for security is
Security through Obscurity; in short: If you don't know its there, you can't hurt it--much like the Ostrich. Well, this took a new turn. File Enumeration basically controls what you can and cannot see based on permissions. If you have the capability of opening the file/folder, you can see it. If you can't, then you got nothing. The one thing that I was impressed was that it works with Mac as well. I loaded up my Mac with 10.4 and mounted the fileshare, lo and behold I could only see the share the account had access to. Unfortunately, I haven't perfected it yet, but, this is roughly what I've come up with:
The
Share$ gets
Authenticated Users. Example: Filestore$
The
Initial Folder gets
Authenticated Users. Example: A (Usernames that start with A)
The
Sub Folders get
Domain\Administrators, and
Domain\%Username%.
By doing it this way, the user can see the path up to the share, but only that. This is inclusive to Mac users. And by combining this with Directory File Share, I can set their login scripts to load \\domain\username$, which points to \\server\share$\folder\folder\. And since the initial share is hidden ($), just browsing the hard drive won't reveal it's location on the file server. I have to play with this more, of course.
However, it doesn't eradicate the problem entirely. Browsing the server still shows all root folders up until the share. This could be corrected by creating AD Groups that only have specific access to those shares, however, this would clutter AD to the point where I'd need a separate OU just to keep it straight. Well, maybe. Let's think about this.
ALL_USERS has access to the entire share. It's membership is "Authenticated Users." In all reality, this isn't necessary, since you can just go for "Authenticated Users."
FILE_STORE_A has access to only the folders under folder named A. It's membership is all users whose username begins with A.
Under folder
A is a separate folder for each user. The membership is based on
%Username%.
If it needed to go deeper, reverse the order of the AD Groups, adding
A to
FILE_STORE_A, which is a member of
FILE_GROUP, which is a member of
ALL_USERS. Might get confusing, but, if you had a treespan of it, it doesn't look that bad. I might just pass it by my coworkers for the sake of security.
Overall, Windows Vista may be a huge flop, but, Windows Server 2008 looks to be very promising. I look forward to promoting it to Domain Controller level and have it start controlling DHCP/DNS on the test network, just for the sake of testing purposes.
