Chris Stauffer at myITForum.com

I will be going on vacation starting this friday the 27 and ending on May 7th. My wife and I have been married for almost 10 years and decided that we (just the 2 of us) need to get away. So we will be going on a 5 day cruise. http://www.pccmusicboat.com/

This will be the first time since the first of our kids where born that we have been able to get away this long (alone).

I'm really exicited because i will have 6 days without kids and computers and 10 days without customers 

Thank god for grandparents (my parents) because without them we wouldn't be able to go ALONE

So if you dont talk to me before then see you on the other side

Chris Stauffer <><

Guess i know what i will be doing when i get back from vacation :-)

 

http://myitforum.com/cs2/blogs/pthomsen/archive/2007/04/25/101423.aspx

 

 

Attachments dont seem to be working so here is a copy of the new ZTI_HalDetect1.2.vbs that i wrote.

Hope it posts ok since nothing else is today.

'******************************************************************************

'//////////////////////////////////////////////////
'//
'// Script File:
'//
'//   ZTIHalDetect.vbs
'//
'//   This script updates sysprep.inf With correct HAL Type
'//   The Reference (master) computer should be built from
'//   an Advanced ACPI computer
'//
'//   Use this script for WIM images (Imagex, OSD, WDS)
'//   Script Written by: Johan Arwidmark
'//   Edited/Logging added by: Chris Stauffer
'//////////////////////////////////////////////////

Const ForReading = 1, ForWriting = 2, ForAppending = 8
set oWshShell= wscript.createobject("wscript.shell")
'Get System Drive
Set objShell = WScript.CreateObject ("WScript.Shell")
strSystemDrv = objShell.ExpandEnvironmentStrings("%SYSTEMDRIVE%")
Wscript.Echo "System Drive: " & vbTab & strSystemDrv

WScript.Echo "Start Hal Check"

Set oFSO= CreateObject("Scripting.FileSystemObject")
' setup script for logging
Set oLog = CreateObject("Scripting.FileSystemObject")
sDate = Date
StrDate = DatePart("m",sDate) & "." & DatePart("d",sDate)
StrLogDir = strSystemDrv & "\MININT\SMSOSD\OSDLOGS\"
Set fLog = oLog.OpenTextFile(Strlogdir & "ZTI_HAL_Check." & strDate & ".log", ForWriting, True)

fLog.WriteLine "Start Hal Check"
flog.Writeling "System Drive: " & vbTab & strSystemDrv
' Customize the local sysprep.inf file based on the HAL type

Call UpdateSysprepinf ()

' Done, quit.

if err Then
    LogFileAppend "I got an error. It was error number: " & err.number & " and the description was " & err.description
    err.clear
end If

fLog.WriteLine "Finished Hal Check"

WScript.Quit

Sub UpdateSysprepinf ()

   ' Find out the HAL type
strsysprep = strSystemDrv & "\sysprep\sysprep.inf"

    sHalType = oWshShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Enum\Root\ACPI_HAL\0000\HardwareID")
 
 strHalType = sHalType(0)
 
    fLog.WriteLine "Hal type Is: " & Strhaltype

   If sHalType(0) = "acpiapic" Then

 if oWshShell.Environment.item("NUMBER_OF_PROCESSORS") = 1 Then

       WriteIni strsysprep, "Unattended", "UpdateUPHAL", "ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf"
 
   fLog.WriteLine "Number of Processors Is one."
   fLog.WriteLine "Hal type changed To: ACPIAPIC_UP"
 
 Else
  WriteIni strsysprep, "Unattended", "UpdateHAL", "ACPIAPIC_MP,%WINDIR%\Inf\Hal.inf"
  
  fLog.WriteLine "Number of Processors is more than one." 
     fLog.WriteLine "Hal type changed To: ACPIAPIC_MP"

 end If

   ElseIf sHalType(0) = "acpiapic_up" Then

 WriteIni strsysprep, "Unattended", "UpdateUPHAL", "ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf"

 fLog.WriteLine "Hal type changed To: ACPIAPIC_UP"

   ElseIf sHalType(0) = "acpiapic_mp" Then

 WriteIni strsysprep, "Unattended", "UpdateHAL", "ACPIAPIC_MP,%WINDIR%\Inf\Hal.inf"

 fLog.WriteLine "Hal type changed To: ACPIAPIC_MP"

   End If

End Sub

Function ReadIni(file, section, item)

    ReadIni = ""
    file = Trim(file)
    item = Trim(item)
    Set ini = oFSO.OpenTextFile( file, 1, True)

    Do While ini.AtEndOfStream = False
  line = ini.ReadLine
  line = Trim(line)
  If LCase(line) = "[" & LCase(section) & "]" Then
   line = ini.ReadLine
   line = Trim(line)
   Do While Left( line, 1) <> "["
    'If InStr( 1, line, item & "=", 1) = 1 Then
    equalpos = InStr(1, line, "=", 1 )
    If equalpos > 0 Then
     leftstring = Left(line, equalpos - 1 )
     leftstring = Trim(leftstring)
     If LCase(leftstring) = LCase(item) Then
      ReadIni = Mid( line, equalpos + 1 )
      ReadIni = Trim(ReadIni)
      Exit Do
     End If
    End If

    If ini.AtEndOfStream Then Exit Do
    line = ini.ReadLine
    line = Trim(line)
   Loop
   Exit Do
  End If
 Loop
 ini.Close

End Function

Sub WriteIni( file, section, item, myvalue )

 in_section = False
 section_exists = False
 item_exists = ( ReadIni( file, section, item ) <> "" )
 wrote = False
 file = Trim(file)
 itemtrimmed = Trim(item)
 myvalue = Trim(myvalue)

 temp_ini = oFSO.GetParentFolderName(file) & "\" & oFSO.GetTempName

 Set read_ini = oFSO.OpenTextFile( file, 1, True, TristateFalse )
 Set write_ini = oFSO.CreateTextFile( temp_ini, False)

 While read_ini.AtEndOfStream = False
  line = read_ini.ReadLine
  linetrimmed = Trim(line)
  If wrote = False Then
   If LCase(line) = "[" & LCase(section) & "]" Then
    section_exists = True
    in_section = True
   ElseIf InStr( line, "[" ) = 1 Then
    in_section = False
   End If
  End If

  If in_section Then
   If item_exists = False Then
    write_ini.WriteLine line
    write_ini.WriteLine item & "=" & myvalue
    wrote = True
    in_section = False
   Else
    equalpos = InStr(1, line, "=", 1 )
    If equalpos > 0 Then
     leftstring = Left(line, equalpos - 1 )
     leftstring = Trim(leftstring)
     If LCase(leftstring) = LCase(item) Then
      write_ini.WriteLine itemtrimmed & "=" & myvalue
      wrote = True
      in_section = False
     End If
    End If
    If Not wrote Then
     write_ini.WriteLine line
    End If
   End If
  Else
   write_ini.WriteLine line
  End If
 Wend

 If section_exists = False Then ' section doesn't exist
  write_ini.WriteLine
  write_ini.WriteLine "[" & section & "]"
  write_ini.WriteLine itemtrimmed & "=" & myvalue
 End If

 read_ini.Close
 write_ini.Close
        If oFSO.FileExists(file) Then
            oFSO.DeleteFile file, True
        End If
        oFSO.CopyFile temp_ini, file, True
 oFSO.DeleteFile temp_ini, True
 
End Sub

Function LogfileAppend(sLogMsg)
    ON ERROR GOTO 0
     Dim iRetVal, fptr
     If Not objFSO.FileExists(sLogFile) Then
         ObjFSO.CreateTextFile(sLogFile)
     End If
     Set fptr = objFSO.OpenTextFile(sLogFile, 8, True)
     fptr.writeline(sLogMsg)
     fptr.close
End Function

 

 

 

I’m working on getting OSD running at the Commonwealth Of Pennsylvania. We presently have it running but we are only able to use a CD to deploy.

 

So I have spent the last 3 weeks off/on working and learning OSD. I want to make it so that any agency can follow the directions that I put together so they can get up and running. I also want to understand how things work so when I get called for support I can assist.

 

During this testing I will be working toward a goal of having 1 or 2 images that will install on any workstation (none server). In an attempt to reach this goal I started playing with this script: http://www.myitforum.com/articles/15/view.asp?id=8997

 

Johan A. did a great job putting this Hal recognition script together. I will be using the VTI_HallDetect.vbs script in this test, But I found that I needed more logging since I couldn’t get the script to run.

 

I added a new log file that is created in the OSDLogs folder. I also added code that will add debug/ error code to the default OSD logs.

 

This was very helpful when I started troubleshooting why the ZTI_HALDETECT script didn’t seem to be doing anything.

 

So I started using a Debug script that I found. Once again this was a script that needed to be tweaked. Anyway this script puts a Archive_OSD.SMS file in the MiniNT folder. I also created a second script to add the file OSD.Debug file to the c drive.

This will allow OSD to keep the logs on the c drive so that you can trouble shot your push if needed. It will also add more debugging entries into the logs. I noted what type of OSD tasks they need to be.

' Note: this doc contains both scripts.
' You will need to copy each one into a different VBScript and setup the task type at the top of each script.
' These scripts will not run in your Desktop OS enviorenment. They are ment to run in OSD PE enviorenment. '*********************
' preinstall task
'*********************
Option ExplicitDim targetPath, env, file2, fso
set env = CreateObject("OSD.Environment")targetPath = env("OSDTARGETDRIVE")
Set fso = CreateObject("Scripting.FileSystemObject")
set file2 = fso.CreateTextFile(targetPath & "osd.debug",TRUE)
file2.CloseSet fso = Nothing

'**********************
'Post Install Task
'**********************

Option Explicit

Dim targetPath, env, file1, fso
set env = CreateObject("OSD.Environment")

targetPath = env("OSDTARGETDRIVE")
Set fso = CreateObject("Scripting.FileSystemObject")
set file1 = fso.CreateTextFile(targetPath & "MININT\archive_osd.sms",TRUE)
file1.Close 

Ok so now I have debugging working but I still couldn’t figure out why the Zti_Haldetect script wasn’t running. So I followed theses directions to get a command prompt in OSD PE http://www.myitforum.com/articles/8/view.asp?id=10052

 

This worked great because now I could run the script manually and actually see if there was a problem.

 

Turns out there was a problem. The script was written assuming that the C: drive was the working directory. Unfortunately in my OSD environment OSD uses the X: drive when it is deploying the Image and after a reboot it gets changed to the C: drive. So basically the script was not executing because it couldn’t find the C: drive.

 

To fix this problem I made another change to the ZTI_HalDetect script. Now the script will check to see what the SystemDrive variable is before it makes its needed changed. Thus saving its changes on the correct drive. The nice thing about this change is that the Script doesn’t care what drive OSD uses it just finds it and makes the changes.

 

Ok well that is all I have on the topic for now. I will have a part 2 coming in a few days ( I hope)

 

I attached copies of the scripts for all.

 

This is sweet. Now why cant MS release this :-) 

http://www.engadget.com/2007/04/17/xbox-360-laptop-mk2/

Its about dang time.

 

http://www.betanews.com/article/Windows_Media_Player_Plugin_for_Firefox_Now_a_Reality/1176826928

 

 

I asked on the Email group

Is there a way to make NetCrawler Discovery run a second time in one day?

I set it up in my lab. I’m trying to get it to discover a workgroup machine, which it did successfully, but I didn’t have SMS/LMHOST/Hosts setup yet. I want to see if I can get SMS to automatically deploy the client when netcrawler runs and I don’t want to have to wait a day between tests.

 Here is the Responce :-)

 I asked Mr. Sugdinis (The NetCrawler man) this question for you, he states;

Yes, just have them setup a scheduled task or sms advert to run a script that does a net stop of the sms netcrawler discovery service and then then a net start of the service. That will allow them to run a disc cycle as many times a day as they want.

 

Rick J. Jones
Cingular Wireless, now the new AT&T
SI - Systems Automation
Microsoft MVP - SMS

Hope this helps someone else.

Chris Stauffer <><

The Microsoft Windows Preinstallation Environment (WinPE) 2004 instance that SMS uses or a customized WinPE instance that SMS updates doesn't have a management console that you can use for troubleshooting purposes. The entire deployment process is driven by the graphical SMS OS Deployment Feature Pack shell. For troubleshooting purposes, you can replace this shell with a "lab" version. This lab shell version lets you open a console session during the WinPE initialization process by pressing F8. While the console is open, the computer won't reboot and you can view any logs that might have been generated (normally created in the C:\minint\smsosd\osdlogs folder) to help ascertain the cause of problems.

The lab version of the shell is called osdshell.lab.exe. You simply replace the standard osdshell.exe with this lab version to enable the F8 ability to start a console session. If you're using a Microsoft Remote Installation Services (RIS)-integrated OS deployment environment, you replace the osdshell.exe file in the OS's system32 folder with the lab version. If you're using a CD-ROM-based deployment, you need to replace the osdshell.exe file in the source folder of your SMS deployment (e.g., C:\sms\osd), then update your OS package files and rebuild the CD-ROM. This process is explained in detail in the SMS OS Deployment Feature Pack documentation in the "Using the Lab Shell for Windows PE" section.

Original article http://www.windowsitpro.com/Articles/ArticleID/45831/45831.html?Ad=1 

 

This is just a word doc version of my last 2 posts since the pics wouldnt post.

http://myitforum.com/cs2/blogs/cstauffer/archive/2007/04/10/cross-forest-client-control.aspx

http://myitforum.com/cs2/blogs/cstauffer/archive/2007/04/10/connecting-a-sms-2003-server-to-a-parent-central-site-without-a-domain-trust.aspx

 

 

 

Cross Forest Client Control

 

This test was done to prove that an SMS site could control SMS Advanced Clients in a different Forest provided that a one way trust was in place.

 

SMS 2003 was tested in a VMware lab environment. I created two separate forests on two separate VM server. Each environment had the following:

• Domain one SMSLAB.OA (simulation of Production forest )
• Windows 2003 SP1
• Domain controller running in 2003 SP1 mode
• DNS
• DHCP
• WINS
• Windows 2003 SP1
• SMS 2003 SP2 R2
• FQDN was used
• SQL 2000 SP4
• Windows XP
• Domain two SMSLAB2.OA2 (Simulation of Application Forest)
• Windows 2003 SP1
• Domain controller running in 2003 SP1 mode
• DNS
• Windows 2003 SP1
• SMS 2003 SP2 R2
• SQL 2000 SP4
• IIS with bits and webdev
• Windows XP

A trust was created between the domains to simulate the trust between the Production forest and the Application Forest. This was a one way trust.

 

The SMS 2003 SP2 server was placed in SMSLAB.OA.

 

I added the SMS server and a service account to the SMSLAB2.OA2 in the form or a Domain Local group. Then this group was added to each system that was tested in the domain. I only tested 2 of the 3 systems below. My results are in the test chart on the next page.

The following Functions where tested:

Test	Results
System Discovery from SMSLAB2.OA2	Successful As you can see in this picture 2 different Domains (forests) are showing in the “all systems” collection
Group Discovery from SMSLAB2.OA2	Successful
Install client Locally OASMSLAB2SMS2	Successful I have logs for this system if you would like to review them. The only problem I saw was an issue with WINS not resolving the SMS server. But it was picked up through DNS. It also had no problem finding the MP.
Install Client Remotely though SMS console OASMSLAB2XP	Successful

 

Package/ advertisement Deployment	8 Successful Deployments including ITMU. The only issue I had here was the Client package Cache size. Once this was increased to 1500 meg all of the advertisements completed successfully.
Remote Control	Successful

I finally got it to work.First I want to thanks everybody who gave their 2 or 3 cents to the problems I had. The MYITFORUM MSSMS Group rules. I had to hack the OSDWinPE.wim file and add the Winbon.ini file to the system32 folder.I was able to hack the image with a program called imageX. It comes in the WAIK for Vista.  To open the Image use this commandImagex /mountrw img_file img_number c:\Mounted_ImagesAdd the Winbon.ini file to the System32 folder then To save the changes use this command ImageX  /Unmount /Commit  c:\Mounted_Images  The winbon.ini file also required a small edit for PE 2005 to disable a popup menu. WINBON.INI Edit [WinPE]Quiet=YesRestart=No I also added a flat folder with all of the network drivers I could get my hands on. Special thanks to the guys on the MYITFORUM MSSMS list. I used USMT 3.0 to do a State Capture I used these files:MIGSYS.XMLMIGUSER.XML I used these switches:/v:5 /o /all I also used USMT 3.0  to do a State Restore I used these switches: /v:5 /o /all I was able to Deploy the image to a windows 2000 SP4 system and upgrade it to WXP SP2.This was all done Though SMS without the need for a deployment CD.It looks like it did a good job moving file (documents).  My LabNote: my lab runs on VMWARE Server 3.2.0My lab has the following servers running :

• Server 2003 SP1 (DC)
• DNS
• Wins
• DHCP
• AD
• Windows 2000 SP4
• Windows XP SP2
•  Server 2003 SP1 /  SMS 2003 SP2 R2 with the following specs
• Site Server - 2.50.4160.2000 (4160)
• Admin UI - SMS 2.50 SP2 (4160)
• SMS Provider - 2.50.4160.2000
• Microsoft SMS 2003 Inventory Tool for Custom Updates(Admin UI) - 2.50.4235.0000
• Microsoft SMS 2003 R2 Vulnerability Assessment Tool Setup(Admin UI) - 2.50.4235.1000
• SMS 2003 Inventory Tool for Microsoft Updates(Admin UI) - 2.50.3616.1000
• SMS Device Management Feature Pack(Admin UI) - 2.50.3635.1232
• SMS Device Management Feature Pack(Site Server) - 2.50.3635.1232
• SMS OS Deployment Feature Pack(Admin UI) - 2.50.3726.2000
• SMS OS Deployment Feature Pack(Site Server) - 2.50.3726.2000
• USMT 3.0
• PE 2005

 

Connecting a SMS 2003 server to a Parent

(Central site) without a domain trust

 

In order to connect a Primary (child) site to a Primary (Central / Parent) site the following will need to be done:

 

• Under Site Server make sure you enter the FQDN for the SMS server
• Created a Local System Service account on Each SMS server
• Add the service account to the SMS_SiteToSiteConnection_XXX Group on each Site server
• Create the Security File for the parent and child sites using these commands:
• (SMS Install Directory)\SMS\bin\i386\00000409\preinst.exe /keyforparent
• (SMS Install Directory)\\SMS\bin\i386\00000409\preinst.exe /keyforchild
• Place the appropriate Security key in the sms\hman directory
• Create a sender on the SMS site settings for the SMS Servers
• On the Central Server create a “Standard Sender” for the child
• On the Child Server create a “Standard Sender” for the parent server
• Create a “Standard” Address on the SMS site settings for the SMS Servers
• On the Central Server create a “Standard Address” for the child
• On the Child Server create a “Standard Address” for the parent server
• On the Child Site go into the Site Properties and set the parent as the Central site.

 

If there is a firewall in place the following ports will need to be opened in each direction:

 

 

Port 445

Server Message Block (SMB)

 

 

There may be additional firewall rules required but because I don’t have firewalls in my lab I was not able to test them.

 

If the SMS Servers do not share the same DNS then a Host entry pointer will need to be added.

 

Posted by cstauffer | 1 comment(s)

Filed under: SMS 2003