Unity Migration Blog

Over the past two weeks I've noticed that when UNI04NT has had performance issues or Apache issues, I would find at the root of each partition on the server large files with the name format of _vxfivspcacheFile*.* These result from Veritas Netbackup not removing the temporary files after a backup is complete. The normally 2 gigs of free space is reduced to megabytes on the System partition. Symantec Antivirus can hinder the timely release of the file, if is not configured to exclude the specific files. Once held open by Symantec AV, I've only been able to clear the files by rebooting the servers.

I've reconfigured the exclusions of Symantec AV on UNI04NT and Scripts00 to hopefully not touch those files. I'll check on the other servers. Any SMS attached drives need to be included in the exclusion.

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?

I've added some monitoring to the LICENSE00 server, which host the KMS licenses for Windows Vista Clients, and the Autocad FlexLM license manager.

In addition to the usual Nagios service checks for Windows Server, there is a small script on the SCRIPTS00 server which runs once a day to generate a status web page. While generating this page, it submits a passive check to the campus Nagios server so that our main monitoring tool can reflect our actual status.

There is also a flexLM license checking plugin that will periodically check the AutoCAD licenses, and give us an alert whenever we max out. I don't have this installed just yet, but when it's installed, it should give us a much better level of monitoring!

Systems where both Veritas Netbackup and Antivirus programs are installed need to have both components configured with exclusions. Otherwise large cache temporary file(s) will not be released and deleted at the end of the backup session. The file has a name in the format of _vxfiVspCacheFile_*.*

READ MORE

It's not done yet, but I'm in the process of moving our subversion repositories off of the venerable wolfprep.unity.ad server, so we can retire it.

When the move is completed, the WolfPrep stuff will all be located under https://svn.unity.ncsu.edu/svn/wolfprep

I've also got a new repository to share things not related to WolfPrep, https://svn.unity.ncsu.edu/svn/itdmicrosys . I hope to have the Remedy to AD group syncronization code, and the KMS license server monitor scripts posted up there "shortly."

Using subversion not only helps keep our source code managable, but it's sooo nice to have anonymous web browser access to things for information sharing and to encourage collaboration. We hope to regularly 'trade code' with groups on campus who have already solved problems that we're just getting our toes into.

Well, with NetBIOS off at least a few hosts, my WMI scripting is begining to work. :-)

We have a new page to track the number of KMS activations for Windows Vista are on our server(s). You'll find it at http://microsys.unity.ncsu.edu/status/KMS-Licenses.html

I intend to repackage this as a nagios plugin that will report "warning" should the actual license count get close to the minimum count, and "critial" should the minimum not be met. This would allow us to get proactive warnings from Sysnews, when combined with proper testing intervals and notifcation rules.

We're starting to flesh out some of the docs regarding how our AD is going to "look" and what folks can expect to find where.

Here's a very ugly and rough start attempting to show the 1:1 relationship between support organizations, remedy groups, and the dfs namespace.

Boring draft image showing that under OU=Organizations in AD there is a 1:1 correspondance to Remedy workgroups

Boring diagram of how the layout of DFS will also correspond to Remedy workgroups

If we map S: to \\unity.ad.ncsu.edu\dfs, it will result in pleasant, short paths like S:\CALS\ZO . It should be clear whose stuff is whose. Groups like CALS and ITECS can easily support other groups in their areas, and the namespace keeps their clients organized. Groups like BAE, that shouldn't get grouped under either ITECS or CALS, will be able to have their own identity, not under anyone's heirarchy, when and where appropriate.

We think there may be folks who do desire a shared locker from us, but who don't want to include a support unit as a middleman. We're undecided how to best handle such a thing, so for a while we're going to show a sort of catch all "OtherSupport" container in our diagrams. We may decide that we can't afford to have "unsupported" groups or individuals, and send them to Distributed Support or our Helpdesk for some sort of help contract, the cost of which could be rolled into the rental price of the space.

We've got some plans for making administration of "locker" space as easy as possible by pre-creating some access groups at locker creation time, but I don't have those docs ready yet.

There are still some things to be sorted out before making any sort of official announcement, but work is progressing towards getting campus wide network booting a reality.

As it stands, we have two servers installed, on in HLB and one in DC2. There are not yet load balanced and syncronized, but that's more an issue of staff time then of relative difficulty. :-)

We have both Wolfprep Windows XP installations, and Realm Linux installations available. I have loaded the Windows Deployment Services binaries up to the server, but as of this moment we don't yet have a functional WDS example.

We have two diagnostic/utility applications available also. Enter "memtest86" from the pxe boot menu to run memory diagnostics, or "delldiags" to run the Dell 32bit graphical diagnostics.

To test any of this stuff, you must set your DHCP template in QIP to "PXE-All" It's unclear to me if this will work on all subnets on campus, but it will by fall. :-)

We plan to support Intel Macintoshes as well, but have not yet built an OS X installation.

When we get WDS, OSX and the replicated servers going, we'll have a big announcement, as we think this is going to have a postive impact on the campus Disaster Recovery stance. Having a central and universal means to deploy workstations will reduce the madness following a disaster to locate both installation media and licensing codes. The tftp servers are configured to be usuable in a "stand-alone" mode should the rest of the infrastructed be unavailable, and have the software pre-installed to offer services like DHCP/PXE should there be a period where QIP based PXE had not yet been restored to service during a crisis.

The server, Script01.unity.ad.ncsu.edu, has been renamed to WSUS00.unity.ad.ncsu.edu, to conform with its current role.
The WSUS related GPOs and the wsus.reg file have been modified to point to the revised server name. DNS has been updated with the current name for the server and its era host name, as well.

In our staff meeting this morning, folks from ComTech and WolfTech came and we chatted about how to implement some DNS updates into QIP from Active Directory.

The intention here is NOT to do client dynamic DNS, but to allow for domain controllers to manipulate SRV records when the DC configuration changes. Right now, SRV records must be updated manually, which is error prone, a PITA, and not fault tolerent.

With the recent QIP 6.2 upgrade behind us, the plan is to bring up a special new name server, for now referred to as "ns50" to serve as the DNS zone master for the various active directory DNS zones. The ns50 server will have an IP based access list of hosts that it trusts (ju st the DCs) and will accept DDNS updates from these hosts. As the DNS zone master, it will then propogate changes to the other name servers and QIP. Clients will be able to read any modified records when they have propogated to the "regular" name servers, but ns50 won't be in the regular list of name servers delivered via dhcp.

Should be a piece of cake (for us, as clients). Once completed, we should be able to promote a new domain controller and have the clients automajically find out about us without having to make manual DNS changes.