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). (more…)
Since my last post I came to the realisation that I really didn’t like the way that the Diskpart box popped up on screen during the function call, so I did what I said I should have done and created the function the other way. This also cleans up the text files after completion, which is something the previous function didn’t do.
For completeness I also made the function a little more generic, so it takes the Volume Label as the Variable, and falls back to “IMAGE” if none was passed.
Function GetVolumeNumberHidden(Label)
On Error Resume Next
Const ForWriting = 2
Const ForReading = 1
If Label="" Then
Label="IMAGE"
End If
Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
TempFile = oShell.ExpandEnvironmentStrings("C:\Temp\dp.txt")
ListFile = oShell.ExpandEnvironmentStrings("C:\Temp\dl.txt")
Set oFile = oFSO.OpenTextFile(TempFile,ForWriting,True)
oFile.WriteLine("LIST VOLUME")
oFile.Close()
oShell.Run "%comspec% /c diskpart /s " & TempFile & _
" > " & ListFile, 0, True
Ouptut = ""
Str = ""
Set oFile = oFSO.OpenTextFile(ListFile,ForReading)
Do until oFile.AtEndOfStream
Str = oFile.ReadLine
If InStr(Str,"Volume") > 0 Then
If Not (Mid(Str,10,3) = "###") Then
DriveLetter = Mid(Str,16,1)
VolumeNumber = Trim(Mid(Str,10,3))
If StrComp(Trim(Mid(Str,20,12)),Trim(Label))=0 Then
GetVolumeNumberHidden = VolumeNumber
oFile.Close
If oFSO.FileExists(TempFile) Then
oFSO.DeleteFile TempFile, True
End If
If oFSO.FileExists(ListFile) Then
oFSO.DeleteFile ListFile, True
End If
Exit Function
End If
End If
End If
Loop
oFile.Close
If oFSO.FileExists(TempFile) Then
oFSO.DeleteFile TempFile, True
End If
If oFSO.FileExists(ListFile) Then
oFSO.DeleteFile ListFile, True
End If
End Function
This function now makes its way into the Completed stage and now I move on to other things. I have been working very frantically on my AutoStore script. This function is used in both the Store/Restore installation, and the AutoStore script itself, in order to get the timestamp of the previously stored image files. Some of the other fun things I have been playing with involve Novell Workstation Policy Packages, and Package Schedules. In order to initiate the AutoStore process I have created an array of Package Schedules that calls my AutoImage.vbe file. I noticed that during the process of Installation, the MSI had not completed before the AutoImage.vbe file was attempted to be run. This lead to a WScript error because the target file did not exist. I modified the run information to the following:
C:\Windows\System32\cmd.exe /c "if exist (
C:\SOE\AUTOSTORE\AutoImage.vbe) (
start wscript C:\SOE\AUTOSTORE\AutoImage.vbe Interval=14 Force )"
At first glance it may seem that some of this can be discarded, however it is all required. In order to first check that the file exists without requiring ANY script to have been installed onto the target machine we need to use “if exist” which requires running through cmd.exe because it is a command interpreter command, not a stand alone executable. If we do not use Start then the command screen stays open while the script runs, or while a popup box explaining to users that they need to reboot is displayed. This appears a disjointed visually and lead to me wanting to close all those blank black windows. WScript does not explicitly need to be called, but since I want to specify WScript instead of CScript I have included it for completeness sake.
In order that the command window does not show up for most of the background calls to the script I have ensured that it runs in the SYSTEM security space. The Unsecure System space is used only for those functions where the script requires user input or provides user feedback. This limits the interruption to the general use of the PCs.
I spent much of the past few days creating and modifying the scripts, and I spent all afternoon packaging the script into the MSI and creating the Policy Packages. I have also now documented the Policy Package creation process and documented the usage of the script. Hopefully I can get it all slapped together and rolled out, as we need to force a store before Monday, when an updated software package is being forced out. I have to love the communication we get prior to these things. I have had to kill myself to get the modifications done to their current point, and as yet they are untested for machines which have not received some of the custom modifications we have implemented. All will come to light tomorrow.
Cheers, Chris
I have spent the last few days creating a few MSI packages and fixing some pre-existing MSI packages. One issue that I found with working on an MSI that installs files to a Hidden partition is that InstallShield has very little in the way of control over partitions, mountpoints and the like. This was not really an issue, as I am using a SOE and can Mount Volumes through VBScript.
The one issue that we had with mounting this specific Volume is that if a USB Drive or a Virtual CD/DVD drive is installed on the machine, it modifies the volume numbering scheme. The volume we were previously attempting to mount was Volume 3. This became Volume 4 in the even that another drive was connected, or a higher number depending on how the USB drive was partitioned.
Not a grand issue, but one that was overlooked by the Corporate boys when they released one of their imaging tools (the hidden volume is the Image volume). I modified their install script to use a bit more smarts when attempting to find the volume it needs.
Function GetImageVolumeNumber
On Error Resume Next
Const ForWriting = 2
Const ForReading = 1
Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oFile = oFSO.OpenTextFile(
oShell.ExpandEnvironmentStrings("C:\Temp\dp.txt"),ForWriting,True )
oFile.WriteLine("LIST VOLUME")
oFile.Close()
set proc = oShell.Exec ("diskpart /s C:\Temp\dp.txt")
Ouptut = ""
Str = ""
Do while Not proc.StdOut.AtEndOfStream
Str = proc.StdOut.ReadLine
If InStr(Str,"Volume") > 0 Then
If Not (Mid(Str,10,3) = "###") Then
DriveLetter = Mid(Str,16,1)
VolumeNumber = Trim(Mid(Str,10,3))
If StrComp(Mid(Str,20,5),"IMAGE")=0 Then
GetImageVolumeNumber = VolumeNumber
Exit Function
End If
End If
End If
Loop
End Function
This function simply uses the output from DiskPart in order to find the number of the volume named “IMAGE”. This is then returned to the call point and can be used in place of the previous DiskPart calls to “SELECT VOLUME 3″ and “ASSIGN MOUNT=C:\Temp\Image”. The only issue with this Shell Exec call is that it cannot be hidden, as then we cannot retrieve the output. This is not a real issue as the Console screen should just flash up and close quickly. Alternatively I could have fed the output into a text file and read it from that, but part of me is always interested in seeing new ways to do things, which was reading from StdOut in this instance.
So this leaves my MSI to be a shell that copies files to an “install” location, then runs a VBScript that mounts the volume and copies those files to the Image Drive. Not ideal, but the best solution I have at the moment. The Corporate guys are considering implementing this in the next version of the Imaging Tool, but in the meantime I will simply replace all the buggy files for my own Administrative Area.
Oh, and I know somebody is going to mention the Shell ExpandEnvironmentStrings call that is unneccessary. This is because it was originally using %temp%. I left it there for now in case I start using %temp% again. Then I can just do a find-replace for “C:\Temp” to “%Temp%” to return it to its previous functionality.
Cheers, Chris.
I haven’t updated you all for a while, but in that time I have completed Microsoft exam 70-290. This ended up being quite a lot simpler than I had originally anticipated. I am currently studying for two more exams. 70-291, which is Microsoft Windows 2003 Networking, and 70-284, which is Microsoft Exchange Server 2003 configuration. I have been attempting the practice exams and reading the MSPress books, and am relatively confident.
I have scheduled both of these exams for the same day, which will make the day a very long one. If I manage to pass both then that will give me MCSA: Messaging Specialist status. I can then focus on the remaining 3 exams to get my full MCSE certification.
I hope to get around to completing my Novell CNA exam at some point soon as well. Or once I have the MCSE I might concentrate on the Cisco CCNA. This will give me the required certification level in order to work overseas.
There are still 2 weeks until the exams, so time to start cramming as much study as I can in.
Cheers, Chris.
Interesting moves happening at work. Today I moved into a Networks role. Originally it was intended that I be doing 80% Servers and 20% Networks due to the solid input I have provided within the Server team to date. This has now been changed to 80% Networks and 20% Servers. The guy who I am filling in for didn’t like the idea of his role being technically abandonned, and I agree with him. There will definitely be some Server Action from my end anyway, because I have a keen interest in running with a few ideas.
Trav and I have approached the Server team with an idea on distributing apps more effectively, relying mainly on network addresses of the PCs to correctly locate an application server. This brings up a few logistical hurdles.
- The restructuring of our Applications such that we can point to a mapped network drive instead of relying on UNC paths.
- The fact that some applications are released with site specific information. As we currently have to modify every new release of these apps to include that information, we should approach the issue from a more managable perspective.
- The Implementation of Login Scripts to Base Drive Mapping on current Network Location instead of the Current Login or Workstation Context or Group (as this then provides a benefit of decreased WAN traffic for Mobile Computers and Distributed Applications).
- The Politics of testing and gaining approval for implementing a new process into something that is seen as a working system. This is possibly the greatest hurdle to overcome in regards to the push for initiative.
At least with respect to point Number 4, Trav and I raised this with one of our counterparts in the Server Team, and although we were given some good reasons why some of the ideas we initially had could not go any further than the drawing board, he did provide some additional ideas on how to proceed to at least implement some positive change so that we can all manage our site specific apps (Point number 2) more effectively.
The thing we need to concentrate on first is going to be appropriating some hardware and then building an environment in which we can test some of our theories that are not being implemented. In the mean time I will start testing some of the ideas that the team has approved at this point.
Hopefully we can implement a ZfS Server that creates NALs under the District Container (as opposed to our site containers) which uses %DEST-APPS1% as X:\ instead of a UNC path, and use a Cluster Wide Login Script to appropriately map X:\.
One parting thought on another issue this could have on us, that the X:\ drive is not consistent around the state. From ZfS’s perspective, everything is all well, however there are a lot more things stored on the X:\ drive that are used constantly from a Technical perspective. This will possibly require some more training, or at least another drive mapping…
Until I start looking into DFS at least 
In three weeks time we shall see what position I am in though, before too many things are set in stone.
Cheers, Chris.
It has been a while since the last update, and that is due to a number of factors:
- Firstly being Family Reasons, I have been given the ultimatum that I spend far too much time on the Computer and not enough with my Family, which I am attempting to rectify.
- Secondly being Workload, as I have been putting in a fair bit of effort at work, and have been exhausted when returning home.
- Study has required a fair bit of time as well, as I am attempting to finish off some of those exams I have neglected for far too long
- Job Applications has taken up time outside of work, as I am busy attempting to better my circumstances due to some positions opening up at my current employer. I have had to cobble together an Application, and am now attempting to get things together for potential interviews.
- Projects and ideas have been coming more frequently of late, as it starts to hit that time of the year (Autumn for me) where I get inspiration and motivation to complete things, so I have been documenting some of these ideas and inspirations and will be endeavoring to get some project work done soon.
So at work I have been involved in a few Scripting Enterprises. The most recent being the AutoStore script. This script effectively checks the age of a Stored Image on the computer, and makes a decision on whether to Store a new Image to replace it. The Image in question is a PowerQuest (yeah, I know that Symantec bought them, and its old tech, but for some reason we are still using it. I hear rumours of Ghost being on the Horizon though) . (more…)
For some of you who know me through some of the other communication mediums I have used, you may be aware that I operate in the same circles as Andrew Russell, who decided sometime late last year (or early this year) to experiment with Coding Outside. Taking a laptop out into the big wide world of interruption, sunshine, and all manner of other things that most nerds avoid.
To get to the point, I have decided to take up where Andrew left off. Having just purchased myself a relatively inexpensive laptop, I find myself now unshackled from the desktop (as I write to you from my bed). Now, this post is not so much to introduce the Dwarfsoft: Outside undertaking so much as to write down a few gripes I have had with this laptop, and getting to the point that I find myself at now.
The Laptop is a Compaq Presario C710TU. This is not an overly powerful machine, yet all I intend to use it for is writing code and doing an occasional build. Most of the work will be rendering text and performing Subversion Commits. One of the major drawbacks of this machine is the standard Memory size. This machine is shipped with 512MB RAM, running Windows Vista. I managed to survive for about a week using a 4GB Flash Drive and ReadyBoost to improve the performance, then I purchased 2GB of RAM.
2GB of RAM was installed, it worked great in safe mode, through memory checks, but as soon as I came to log in to Vista … BSOD. The dreaded Blue Screen had come back to plague me. So I started doing some Internet searches to track down this issue. The Error was a Page Fault by a driver attempting to access memory in a non-paged area. The driver was igdkmd32.sys. From my searching I managed to find out that many people had this issue, usually while trying to run some game or another, and yet there was no actual solution posted.
I attempted to reply to these threads (on MSDN mainly) in order to shed some light on some of the poor souls who were experiencing the issue, but for some reason the threads had been closed or locked. That was when I decided to write up here, just in case somebody else needed to find the solution to this issue.
The solution to the problem, as those of you who have worked with installation and repair of PCs for some time may already have noticed, is the driver for the Intel onboard graphics card. The latest drivers can be obtained from Intel by going to the “Support and Downloads” section and Searching for “Mobile Intel 965 Express Chipset Family” (This also covers the Intel 960 Chipset). By Installing this driver, the issues were resolved.
What irked me the most about this whole process is that I visited the Vendor website after resolving the issue, and the drivers up on the site are the same ones that came preinstalled with the laptop, which are now 5 months old. There have been 2 BSOD fixes to the drivers since that version, neither specifically for what I was experiencing, but it could have been an underlying issue that was resolved.
So, here ends my rant about the comprehensiveness of a vendors driver packages, but stay tuned as I bring you all up to date with the Dwarfsoft: Outside adventures after my trip to the Library, and the Hospital over the past few weeks.
Cheers, Chris.
The USB Drive Letter Fix Files have been uploaded, and have been linked to in the original “Still Scripting” blog. If you missed these files before, here they are again:
ListDrives.vbs and FixUSBDrives.vbs.
Cheers, Chris.
Next Page »
Print This Post