Dwarfsoft [GPA]

I will start out by simply stating how much I HATE SEP11, and how it handles client scan logs. For some reason there is NO way of getting a client scan log out of the Central Management Console. The whole point of Central Management is being able to … manage CENTRALLY.

Anyway, enough rant. I wrote a batch file to pull the latest (or specified) log file from a list of servers (in a file called Servers.txt). More Source: (continue reading…)

As you may know, I posted a while ago about how to handle INI files using VBScript if you can’t use the Word.Application object System.PrivateProfileString function.

Over at CodeProject there has been a more recent submission which includes a VB.Net, C# and VBScript solution that is a little more elegant than mine. It uses Regular Expressions to parse the INI File (which I would use now if I had been building it now), but still utilises the Scripting.Dictionary object for organising sections, keys and values.

Enjoy,

(continue reading…)

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…)

Recently I have been working on some rather complicated projects preparing our SOE to move from Novell eDirectory to an Active Directory environment. One of the packages I built was required to run periodically and so I set up a Scheduled Task to accomplish this. Rather than introduce a security risk by creating a new Administrator Account I just created the scheduled task to run as the local SYSTEM account. It turns out that the SYSTEM account does not have as much access as I required, especially when managing user registry hives.

After quite some time looking in to how to achieve my goal I came up with a rather simple, yet ultimately hacky, solution. Give the SYSTEM Account Administrative Privileges.

(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…)

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…)

Before I jump in to the fun that is the Scripting that I have been wading through this past week, I thought I’d let all of those who may care that I finally have some kind of certification. I passed Microsoft exams 70-291 and 70-284. So I am now the proud holder of a Microsoft Certified Systems Administrator Messaging Specialist certification (MCSA Messaging). Now I am concentrating on the final three exams so that I can get my MCSE.

After a rather hectic week of scripting a solution and then distributing it under an excessively short deadline, I have been asked to provide stats on the result of forcing this solution out to clients. The solution that I had to develop keeps tabs on a System Volume Image of PCs, and ensures that this Image never gets out of date too far. Currently I am not forcing a Store every restart, as the planned solution was to do, but I do inform the client that their current Image is out of date and ask them if they want to do a Store now. If they click on Yes then their PC is rebooted and the Store is done (providing that one of many flaws in the current Store process do not interrupt the process). (continue reading…)