Unity Migration Blog

Hey folks,

I'd like to reawaken our discussion of Windows Share +/- NTFS file permissions for Friday's pilot meeting.

I won't duplicate the old blog post with a repeat of the background info, but would appreciate it if you'd review it before Friday's meeting so we could discuss our "best practice" stance.

Some Microsoft documentation is suggesting different practices, see http://microsys.unity.ncsu.edu/blog/index.php?title=gpo_creation_problem_solved&more=1&c=1&tb=1&pb=1 for context.

Another beautiful theory, shot down by ugly fact.

I can't seem to associate software with computers as "published" -- it seems to want assigned or nothing.

So the plans just posted are pretty much as bust.

Shall we re-create the idea of an AppTesters group, so that we can publish applications to them?

For what it's worth, I've broken the PuTTY application while messing with this. Shouldn't impact you if you've already installed it to C:, but it's unavailable for installation while I try to figure out how to best proceed.

I've created OU's for each of us under the "Unity Computers/Application Testing" container.

OUs under "Unity Computers/Application Testing"

I have not set any permission or group policies on these OUs (well, I've started working on my own, but nobody else's).

Andy was going to review the GPOs assigned to Application Testing to set some minimum folder redirection and other necessary bits, but not try to deliver the entire look and feel, as this might impair testing.

The plan, as I understand it, is that we will create two GPOS to deliver each of the MSI based applications that we deliver. One will be "published" and one will be "assigned." Use the same naming convention used in the file system for an app, separated by dashes (eg "BMC Software-Remedy-7.1.01-Assigned")

A published application appears in add remove programs, and so can be optionally installed. Assign apps to be tested to the "Applications Testing" ou as PUBLISHED. We will use the assigned flavor to test the interaction of many assigned apps, but most folks want control of when things are installed during testing. If you need to test the assigned version, do it in your own OU

Use microsys list and cc Tom & Ed for now to communicate about app testing availability

We're still looking into details about 'categories' and don't have a best practice guide developed just yet. Making the containers and identifying the test container is just the first step.

The following document caught my eye in the last notes from the Senior Staff meeting:

BE encouraged everyone to scrutinize the draft new High Security Data Server Minimum Security Regulation for the possible implications for academic users and departments. (The draft is online at http://www.ncsu.edu/it/uitc/07-11-07/HSDServerReg-draft06-13-07.doc.)

Reading the document, I think the "lockers" that we offer (in both AD and NDS space) can easily meet these requirements, which seem to mostly be good general practice and good general documentation standards.

One thing that we might have trouble meeting is the requirement to document what "high security" data is actually stored on our servers. Up until now, content has been completely up to the person requesting the space.

"It would be nice" (sm) if we could meet the requirements of this doc for groups who had sensitive data they wanted to keep but didn't care to run their own servers. Two ways that I can think of would be to see if we could document the physical security in a format acceptable to the security auditors, but refer queries about what is actually stored to the owner. We'd need to explicitly state that we were sharing contact info for this purpose, of course. The second method would be to provide in a secure space some sort of wiki-like documentation system for clients to enter and maintain the required auditing information.

As we get closer to establishing our locker practices, I'll touch base with the security guys to see what they desire. In the meantime, anybody have any thoughts on this or how to implement it?

For the packages that aren't from a traditional vendor, what if we named the folder under applications based on the primary web site for the project?

For example, the "TrueCrypt" software that the folks in the Security group have requested could live under "truecrypt.org\TrueCrypt 4.3a" This would allow us to keep our namespace "flatter" (we'll have thousands of entries under "NoVendor/Free/Sourceforge/Whatever in the limit) and still organize multiple versions/platforms.

Nays/yays?

Folks,

At our last staff meeting, we decided that we'd like to store the AFS path information for where people's home directories live in AD, rather than use either the hesiod or ldap(.ncsu.edu) databases. The reason being that we want to support authentication off of campus (ldap.ncsu.edu only serves privacy data on-campus) and comply with FERPA (hesiod can't, ever).

Most of the school's that I surveyed simply used "homeDirectory" to store these paths, but we want "homeDirectory" to be the user's Windows home directory, not AFS. So what we needed was a unique ldap attribute/OID number to store AFS info.

I chatted with Daniel, and NCSU has the following OID's already defined:

http://www.ncsu.edu/it/systems/documentation/tiki-index.php?page=Registered+OIDs+for+NCSU

This is a secured page, so I apologize if you can't read it. :-)

The useful bit is that we have an attribute, 1.3.6.1.4.1.234.1.15, "ncsuAFSPath" designed for this very thing.

I plan to extend the UNITY.AD schema at wednesday's staff meeting. I'd like to review the other entires on this list with the folks in Microsys, so we can add any other bits that the group may need.

This post describes some tests that were conducted to confirm the behavior of the sAMAccountName attribute and if disabling NetBIOS over TCP/IP has any effect on it.

My believe is that the sAMAccountName attribute must be unique across the entire domain even if NetBIOS is disabled on every machine and server. This assumption is based on Microsoft's documentation regarding security principals. Computer, user, and group objects are security principals. Each of these has a mandatory sAMAccountName attribute.

READ MORE

Microsoft Virtual PC can be used to easily install and test ITD's new environment and installation methods without having to sacrifice any hardware.

Disclaimer: This is not any sort of announcement that people outside of ITD should test the new environment.

What you need:
Microsoft Virtual PC 2007 (Download)
ITD's Pilot Installation CD ISO (Download)

Configure Virtual PC
Install Virtual PC and create a new virtual machine. Configure the virtual machine to use at least 10 GB of hard drive space and at least 512 MB of memory. (Yes, these numbers are arbitrary)

Important: You need to select your wired network adapter under the virtual machine's networking settings. A wireless card, Shared Networking (NAT), and "Local only" probably won't work.

Virtual PC assigns a different MAC address to each virtual machine and these MAC addresses are not the same as the one your host PC is using. You need to register the virtual machine's MAC address in QIP and configure it to use M-DHCP.

If you already have another virtual machine that is using a MAC address registered in QIP, you can force the new virtual machine to use the same MAC address so you don't have to register another one.

Open the following file to view or modify the MAC address that the virtual machine will use:
My Documents\My Virtual Machines\*VM NAME*\*VM NAME*.vmc

You should see a line like this:
[ethernet_card_address] type="bytes"0003FF0E9EC2/[ethernet_card_address]

Note: greater than and less than signs were replaced with brackets in the line above because the blog software gets confused.

This line can be edited to use a MAC address that has already been registered in QIP to use DHCP from another one of your virtual machines. If you haven't already registered an address, use the MAC address from this line when configuring QIP.

Boot to the Installation ISO Image
From the CD menu in Virtual PC, select "Capture ISO Image" and then select the location of the pilot-install.iso file that you downloaded. Start the virtual machine and it should boot to the ISO file and Windows PE should start up. You should not have to do anything after this point thanks to Microsoft's "Zero Touch Installation" magic. The operating system should install, add the appropriate drivers, add the virtual machine to the domain, and eventually you should see the Windows XP logon box.

Tip: When Windows PE boots up, press F8 when you see "Initializing Windows PE".

This will cause a command box to appear. This is useful if you have any trouble. The most likely problem will be if networking isn't working. You can run ipconfig /all to make sure the virtual machine successfully receives the IP address you registered.

I am at an impass regarding NetBIOS being disabled on some of our servers and could use a little help. If NetBIOS is turned off on a server, you cannot access that server if you have the Novell Client installed on your workstation. We already knew that.

This message appears if you try to access a share on a server with NetBIOS turned off if the Novell Client is installed:

The ideal solution would be to find a way to configure or disable features of the Novell Client which would allow access to a Windows server with NetBIOS turned off. There are administrators all over campus who will need to administer the old and new environments concurrently. We should not expect them to have to maintain multiple desktops in order to do their job and administer the services we deliver. That would be quite an imposition. We could provide a VCL image with adminstration tools. This will be helpful but there are often situations where an administration task needs to be done in a hurry and waiting for a VCL lease is not acceptable.

I tried reordering the provider order on my workstation putting "Novell Client for Windows" last. This did not make a difference.

I disabled the "Novell Client for Windows" binding. This didn't help either.

With the binding disabled, I disabled SLP and every other Novell networking option I could find. This still didn't make a difference.

My workstation had been running Novell Client 4.91 SP2. I tried upgrading to 4.91 SP3. It would not let me. This error appears:

I finally gave up and tried uninstalling the client from my workstation. It seemed to uninstall and I rebooted. I still couldn't access the server with NetBIOS disabled. I don't think the client fully and cleanly uninstalled itself. Uninstalling the Novell Client can be an onerous task. We should not expect campus administrators to have to deal with this.

I have not found a solution to the error shown above. I have no plans to reinstall my workstation and would like to access shares on all of our servers. At this point I cannot access our web server from my workstation and am not able to add content. WebDav has been mentioned. As of now I have been trying to solve the underlying problem and have not tried WebDav.

And I thought there'd be a simple group policy setting I could apply to remove NetBIOS from our workstations and servers ... :-0

It turns out there is no such policy, and that the registry keys that store the NetBIOS configuration for an adapter are dynamic, which makes it troublesome (!) to whack out a cust .adm file to take care of it.

A script seems to be the only way to disable NetBIOS, or turning it off via DHCP. Since set DHCP options very coarsely, it's no good to set things there. The client-32 workstations for example still "need" NetBIOS after a fashion.

So here's a Microsoft script to turn off NetBIOS over tcp/ip, which I'll package into a GPO as a startup script. Oh, the effort required to free ourselves from running WINS... Perhaps we should have given up sooner!

Enables NetBIOS for a network adapter. To enable NetBIOS via DHCP, pass the value 0 to the SetTCPIPNetBIOS method (instead of the value 1). Pass the value 2 to disable NetBIOS.

On Error Resume Next

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colNetCards = objWMIService.ExecQuery _
("Select * From Win32_NetworkAdapterConfiguration Where IPEnabled = True")

For Each objNetCard in colNetCards
objNetCard.SetTCPIPNetBIOS(1)
Next