Pro/Server – 7/13/2009

Ok, first off, can anyone else believe it’s already mid-July?

Yeah.

So here we are in week 3, and according to the syllabus, we’re slated today to cover chapters 7-9.  I decided to go ahead and squeeze 10 in there as well, so that we’ll have plenty of time next week to spend on IP addressing.  More on that, well, next week.

Starting with Chapter 7: NTFS permissions.  Understanding NTFS permissions is key if you want to pass many Microsoft exams, and it’s actually pretty easy if you let it be.  One of the benefits of using NTFS is that we can indicate who we want doing what what to the files on our system.  It’s a great way to keep certain files secret and to make other ones available, dependent upon which group(s) a particular user is a part of.

But what if a particular user is a member of more than one group, and each of those groups have differing permissions?  This is precisely where people can start glossing over, if they’re not careful.

First of all, it’s important to know that we can assign either an Allow permission, a Deny permission, or no permission at all.  If, as a member of HR, I am allowed Full Control on the Payroll.xls file, then I can do anythign I want to with that file.  But imagine that I’m also a member of the finance group, who has been assigned Read Only rights to the file.  We have two conflicting rights assignments.  One says that I can have full control, the other says I am allowed to Read Only.  Which prevails?

In this instance, since I have two “warring” Allow permissions, then the most lenient wins.  In other words, I would be able to have Full Control over the Payroll.xls document.

What if, instead of belonging to the Finance group, I belonged to the HR and the Interns group?  Assuming I still have the same Full Control permissions as before being a member of HR, but as an Intern, I have *no* Allow permissions set (or Deny), then what happens then?  The answer is derived the same way as before — the most lenient wins.  So, in one group I *am* allowed Full Control, the other I am not, so therefore, Full Control wins.

The game changes slightly whenever a Deny permission enters the picture.  See, Denies override EVERYTHING.  For example, I can be Captain Admin at an organization, and be a member of 99 groups that give me full control over the Payroll.xls document.  If I’m a member of even one group that Denies me access to that particular file, guess what?  I AM DENIED.  No questions asked.  It’s really kind of dangerous, and so advisible to only use Deny permissions whenever there’s a compelling reason to.  (A great example is in teh case of hiring interns.  You probably don’t want unpaid college kids looking through your company’s private data.  I’m just saying.)

Anyway, we next moved on to Chapter 8, which dealt with Folder permissions.  Folder permissions are kind of like watered-down NTFS permissions — they basically work the same way, however we don’t have as many options.  Folder (or share) permissions have on advantage (if we want to call it that) over NTFS permissions in that they are not tied to the file system, and so become file system-independent.  What this means is that we can have either FAT32 or NTFS systems participate in the permissions, whereas NTFS permissions can only exist in an NTFS system.  Any old 9x machines that you may have still lingering on your network can only recognize folder shares, so keep them handy.

(As an aside, I have one lingering Windows ME computer on a network for the elementary school I consult at, and one of my Twitter followers has a batch of Windows 3.1 machines he still maintains on his network.  It’s rare, but we do still see these old OS’s!)

Chapter Nine was a discussion on Windows installer.  Windows Installer is basically a shell for the old .exe’s that give admins a whole lot more control!  The dilemma for a long time was whether to give end users enough persmissions to install the programs they need, or to make IT staff do it — which inconveniences the user and takes up IT time and resources.  A solution to this is the use of .msi files which give the administrator a good deal of granular control.  For example, with an .msi file, an admin can publish/assign an application to any group of users, a particular site, or the entire network with just a few clicks of the mouse.  In addition, with .mst (transform) files, we can very easily make updates to our .msi packages.

Chapter Ten discussed connecting Windows XP to a network.  We looked at the two most common ways, using TCP/IP and NetBIOS, and we also poked around a bit with Novell Netware.  In the real world, using the former two methods will be the way you’ll probably network your client machines, but be aware that tehre are still some Netware installations hanging around out there.

Not only that, but chapter ten has us discovering Remote Desktop.  I have been using Remote Desktop technologies for years now (VNC, anyone?), and I’m still amazed at what is actually going on.  I am literally controlling one computer from another one, many times across the Internet.  How cool is that?  Anyway, we looked at getting Remote Desktop set up, and here’s a summary of the requirements that you’ll need in order to implement that on your network (assuming WinXP):

1. Go to the Remote tab of your Systems Properties.
2. Put a check mark in the Enable Remote Desktop check box.  If you don’t have this check box, you have XP Home Edition, which does not support Remote Desktop.  Sorry.  Upgrade.
3. Make sure the user account you use is in the *target* computer’s Remote Desktop Users group.  By default, the local administrator account is included there.  If you don’t have the local admin credentials (and in some places you won’t), you’ll need to make sure your boss sets you up with an account that can be included in the Remote Desktop Users group, or you’re not getting anywhere.

Ok, WordPress is telling me I have well over 1,000 words in this post, and I think it’s high-time I stop typing.

Homework:

• Take Home Test 3 – download it here.