Dwarfsoft [GPA]

I had started another post on Group Policy editing, and how the Policy files are structured, and how to use and improve on the existing Group Policy Editor tool. The post has been found to be far too epic, so I have decided to cover a smaller subset of recent finds.

As everybody is probably already aware, we use Novell ConsoleOne and Zenworks where I work. ConsoleOne has some interesting features that require that whenever a Group Policy is being edited it takes over as the policy on the machine that is editing it. Rather than have a useful tool like Microsofts Group Policy Management Console, Novell likes to replace the local Group Policy and then just run gpedit.msc. Which is where my first gripe about gpedit.msc comes in:

GPEdit.msc requires line by line entry of things like, for example, port exceptions and program exceptions for the Windows Firewall. This is usually not an issue except that, as I have discussed in previous posts, we have been moving towards a Windows Domain environment. Firewall Exception rules are configured within two places in Group Policy: Domain Profile and Standard Profile. I have found that there is a need to move our current Standard Profile settings across to the Domain Profile settings. After a bit of registry searching I found a neat trick for doing exactly that.

(continue reading…)

I have recently been having a look into determining the Last Login Time of a user for a BGInfo implementation. Firstly I had a look at the getCurrentUserLastLoginTime script suggested for use with BGInfo. The limitation of this script, however, is that it will reset the login time to the last time the Windows login box was Authenticated against, which also includes the time that the workstation was unlocked.

In order to maintain current BGInfo information the implementation is running periodically, so this is unnacceptable. Therefore I had to work to resolve the issue manually. As I have had a fair bit of experience with Windows Profiles recently (see the last blog post) I was familiar with the ProfileLoadTimeHigh and ProfileLoadTimeLow registry keys in the ProfileList. So I set out to determine how to actually use these to determine the login time. I first wrote some code to get the User SID based on the users “%userdomain%” and “%username%”:

(continue reading…)

As promised, here are the scripts required for the Pre-staging of Domain User Profiles on the local machine. The first thing we need to do is Enumerate all the Local User Accounts.

Function StageAllUsers(DomainFQDN, strDomain)
   ' Enumerate all users that are Local and not built in accounts.
   strComputer = "."
   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
   'Enumerate users where the User Domain is the Local Machine
   Set colItems = objWMIService.ExecQuery _
                  ("Select * from Win32_UserAccount " & _
                   "Where Domain = '" & GetComputerName & "' " & _
                   "And Disabled = FALSE And Name <> 'Administrator'")
   ' Stage each user
   For Each objItem In colItems
      ' Ensure the account actually has a profile (otherwise we can ignore it)
      If GetLocalUserProfile(objItem.Name) <> "" Then
         ret = StageUser(objItem.Name, DomainFQDN, strDomain)
      End If
   Next
End Function

The functions called here are GetComputerName, which returns the name of the local machine, and the other important ones are GetLocalUserProfile and Stage User. The first we can check is GetLocalUserProfile. (continue reading…)

Well, I have been very slack in that I haven’t updated with my Group Policy investigations or the eDirectory VBScript classes I was working on, but what I have been involved in recently is working on Migrating Workstations from Novell eDirectory to Active Directory.

In this process I have come across an array of options in migrating accounts from a Local User account to Domain User account and transferring the profiles across to keep the user “look and feel” that they are accustomed to.

One problem: In this scenario it makes for a very manual rollback strategy, no matter how much scripting and automation is involved in the migration process. This boils down to Novells implementation of “Dynamic Local User” which effectively creates a Local User Account that is not really bound to a User Account in eDirectory for Authentication or mapping purposes (which you can see if you look at the account SIDs).

(continue reading…)

I have updated my GTD-PHP Email Import Addon so that it now integrates with the current Subversion revision of the code. There is one bug left in it, in that it will not check that there is a mail server set before it tries to connect. I find that this error occurs the first time the session is established with the server, and from then on it works fine. By performing an error check against $server = “” I should be able to remove that bug as well.

The updated EmailImport Addon is now available for download from the GTD-PHP Trac wiki.

(continue reading…)

So I have been using the new script this morning, and testing adding new actions from the GroupWise account at work. Here is where I encountered some issues.

GroupWise decides it wants to MIME Encode the email, which brings about my first problem. I need to account for multiple MIME Parts. After resolving this my next issue is that the corporate email gateway decides to append a massive disclaimer at the bottom of the email, bloating my item by at least 1000%. So I implemented the ability to cut out disclaimers based on a stripos call. I can have a list of different filters here and it will cut them all out.

After fixing this up and resolving the functional issues I logged this addon as a ticket in the GTD-PHP Trac system.

(continue reading…)

I have been attempting to get a fully working system set up for David Allens Getting Things Done. To this end I have set up an install of GTD-PHP.

Being the kind of person who likes to adapt, change, and implement better solutions, particularly for myself, I created a list of features I would like to see in my GTD-PHP installation. One of the first problems I had with the existing system was that it does not support importing Inbox items from a real mail Inbox.

I did some research and came across an existing mail importer, however this required directly piping mail from SMTP into the php script, which I could not do on my host (or would prefer not to do).

(continue reading…)

I was required recently to audit passwords on all the Novell GroupWise accounts in the cluster. This was not too much of a problem using existing solutions, except that all the existing solutions limited searches to either Users, or to objects with the “NGW: Object ID” attribute.

The Solutions I found include Check GroupWise Users for Password – Batch and Check GroupWise Users for Password – Exe, both of which made use of GWSend. Being an avid scripting aficionado myself I opted for the first, so I could make changes.

First step was to export all User Objects with NGW: Object ID into an Excel sheet using DSReport. Then export all GroupWise External Entities with NGW: Object ID to a different Excel Sheet. Finally I needed to export all GroupWise Resources, which do not have an NGW: Object ID, but their CN is effectively the NGW: Object ID for which we can log in and try to send emails. Upon completing this I compiled a single list of Allusers.csv which had the NGW: ObjectID/CN in the first column, and the DN for the Object Name and Location within the tree. This makes it far easier to track down the location of generic accounts (Something that none of the scripts account for).

(continue reading…)

It has again been some time since my last update. I have been quite busy getting used to balancing my new life with my daughter now nearly 3 months old. Fatherhood has obviously taken a lot of my time that I previously used for development, and learning.

The past few months have also seen my University Graduation 3 days after my Daughters Birth, Family Visits, Job Applications, Job Interviews, and finally Permanency in my Servers Position.

Aside from that I have been working with some friends on converting the old TA Server to the C# .Net/Python version (PyTA). I have also been busy in mapping out my development goals and objectives for the coming months and years.

(continue reading…)

I was recently working on an issue to do with managing .ini files in VBScript. I know what you are all going to say now: Why would you use an INI file when the registry is available for use?! Well, there is one instance that you may wish to use another form of configuration or information passing. In this instance we have an initiation of the Ghost Store method for the System Volume. To achieve a store on the system volume we require the PC to be rebooted and it then boots up into a BartPE environment to run the Ghost Store, and perform a few custom tasks. Therefore, the System Volumes Registry is not present (or requires mounting then reading, which has proven somewhat unreliable for me in the past).

So, the reason it came to developing the Ini file handler class is due to the need to provide some more controlled smarts into the store/restore system. Clusters, such as the one I work within, can be more proactive in their maintenance, and therefore require more advanced features than the corporate stock-standard release is likely to contain. As such the area in which I work is constantly involved in working towards a very automated maintenance process. My skills, lying within scripting, programming, and automation in particular, come in handy in this regard. I regularly disassemble the corporate releases to ensure that they will not break when released out into the wild of our corporate machines.

(continue reading…)