none
PageFile Script

    Question

  • Well its been years of me using this amazing script with 100% success in maybe 1000 XP custom installs but it's time that my XP clients are all converting to WIN7 and I have been working on a new custom install. I simply do not have the skills to figure out the changes to make this work in XP (and yes I tried) so I was wondering if anyone could assist.

    I had been using RunOnceEx to copy both files to the root and then call the script it worked perfectly to adjust the pagefile based on the amount of memory a system had.

    500_Settings.ini

    [Global] Verbose=False [ConfigPageFile] SizeRelativeToRAM=2

    '==========================================================================
    '
    ' VBScript Source File
    '
    ' NAME: 160_PageFile.vbs
    ' VERSION: 1.5.0.0
    '
    ' AUTHOR: David R. Stein
    ' LAST UPDATED: 09/18/2008
    '
    ' COMMENT: This script configures the page file to be a static size.
    '
    ' CHANGES FOR THIS VERSION:
    '   * Began implementation of logging.  The file ScriptPack.log is created
    '       in %SystemRoot%.
    '   * If the file 500_Settings.ini is not found the script will quit.
    '
    '==========================================================================
    
    Option Explicit
    Dim ws, fs, sysdrv, LogFile, colDrives, objDrive, strOEM, OEM, INIFILE
    Set ws = WScript.CreateObject("WScript.Shell")
    Set fs = CreateObject("Scripting.FileSystemObject")
    sysdrv = ws.ExpandEnvironmentStrings ("%SYSTEMDRIVE%")
    Set LogFile = fs.OpenTextFile(sysdrv & "\ScriptPack.log", 8, True)
    Set colDrives = fs.Drives
    For Each objDrive in colDrives
    	If objDrive.IsReady Then
    		If fs.FileExists(objDrive.DriveLetter & ":\CDROM_NT.5") Then
    			strOEM = objDrive.DriveLetter & ":\OEM"
    		Elseif fs.FileExists(objDrive.DriveLetter & ":\WIN51") Then
    			strOEM = objDrive.DriveLetter & ":\OEM"
    		End If
    	End If
    Next
    If fs.FileExists(sysdrv & "\" & WScript.ScriptName) Then
    	OEM = sysdrv
    Else
    	If fs.FileExists(strOEM & "\" & WScript.ScriptName) Then OEM = strOEM
    End If
    If fs.FileExists(OEM & "\500_Settings.ini") Then
    	INIFILE = OEM & "\500_Settings.ini"
    Else
    	WScript.Quit
    End If
    
    '**********************************************************************
    '** Function; Reads entries from the ini file                        **
    '**********************************************************************
    Function ReadIni(file, section, item)
    	Dim ini, line
    	ReadIni = ""
    	If fs.FileExists( file ) Then
    		Set ini = fs.OpenTextFile( file, 1, False)
    		Do While ini.AtEndOfStream = False
    			line = ini.ReadLine
    			If line = "[" & section & "]" Then
    				line = ini.ReadLine 
    				Do While Left( line, 1) <> "["
    					If InStr( line, item & "=" ) = 1 Then
    						ReadIni = mid( line, Len( item ) + 2 )
    						Exit Do
    					End If
    					If ini.AtEndOfStream Then Exit Do
    					line = ini.ReadLine
    				Loop
    				Exit Do
    			End If
    		Loop
    		ini.Close
    	End If
    End Function 
    
    '**********************************************************************
    '** Subroutine; Page File configuration                              **
    '**********************************************************************
    Sub ConfigPageFile
    	Dim strComputer, SizeRelativeToRAM, objWMIService, objSWbemServices, colPageFile, colSWbemObjectSet
    	Dim objSWbemObject, SystemRAM, PageFileSize, objPageFile
    	strComputer = "."
    	SizeRelativeToRAM = ReadIni(INIFILE, "ConfigPageFile", "SizeRelativeToRAM")
    	Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
    	Set objSWbemServices = GetObject("winmgmts:\\" & strComputer)
    	Set colPageFile = objWMIService.ExecQuery ("SELECT * FROM Win32_PageFileSetting")
    	Set colSWbemObjectSet = objSWbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")
    	For Each objSWbemObject In colSWbemObjectSet
        	SystemRAM = objSWbemObject.TotalPhysicalMemory / 1024
    	Next
    	If SizeRelativeToRAM > 32 Then
    		If SizeRelativeToRAM > 4092 Then
    			PageFileSize = 4092
    		Else
    			PageFileSize = SizeRelativeToRAM
    		End If
    	Else
    		Dim TempPFZ
    		TempPFZ = SizeRelativeToRAM * SystemRAM
    		If TempPFZ > 4092 Then
    			PageFileSize = 4092
    		Else
    			PageFileSize = TempPFZ
    		End If
    	End If
    	For Each objPageFile In colPageFile
    		objPageFile.InitialSize = PageFileSize
    		objPageFile.MaximumSize = PageFileSize
    		objPageFile.Put_
    	Next
    End Sub
    
    '**********************************************************************
    '** Run Tasks                                                        **
    '**********************************************************************
    LogFile.WriteLine(Date & " " & Time & " - " & WScript.ScriptName &  ": Begin")
    ConfigPageFile
    LogFile.WriteLine(Date & " " & Time & " - " & WScript.ScriptName &  ": End")
    LogFile.Close
    If fs.FileExists(sysdrv & "\" & WScript.ScriptName) Then fs.DeleteFile(sysdrv & "\" & WScript.ScriptName)
    


    Monday, April 02, 2012 2:32 AM

Answers

  • JRV,

    I appreciate your response and I agree with quite a number of your comments but not all of them and still prefer to set a static page file size. I would also never consider letting XP manage the size so that I clearly differ with you on. The beauty of this script was the fact that it was "smart" it checked how much ram you had and adjusted the size to accomodate that up to the max of 4 gig since it was written for 32 bit systems. I now only deploy x64 WIN7 so this script is useless to me.

    Since I am looking at probably 500 deployments if I cannot get the script to work then I will just let WIN7 manage it... thanks again

    It would bemush easier to use an unattended install file to set al of these things.

    Look at the MDT.  The new one allows you to manage almost everything in a config file and stil  allow custom scripts to be run during installation.  It will even jin your domain and set the OU.

    It has always been cleaner to allocate the page file duriong setup rather than after the system has started. 

    Yes - changing this script may be a waste of time with Win7 although you can still pre-allocate. The recommended method for doing WIn7 is to let WIndows manage teh page file.  This was not the case in XP.  XP alocated the file based on memory with 1.5 time memory as the upper bound.  I used to preallocate a full 1.5 initially to pervent disk fragmentation. Later XP installs I stopped this as teh defrag utilioty could aggregate the page file if it was extended.  On the newer larger disks this produced about the best performance as long as we oredered the systems with at leas 2Gb of memory. Later 4Gb was the best purchase and produced best liftime performance.  Now with Win7 64 we can just put 8Gb in to begin with and stop tuninking about memory issues.  Of course this is not the best approch for servers but works extremly well for workstations.

    I think you can be comfotable with Win7 memory defaults or use an unattended file.

    Here is a blurb from MS:

    You’ll notice that the default configuration is for Windows to automatically manage the page file size. When that option is set on Windows XP and Server 2003,  Windows creates a single paging file that’s minimum size is 1.5 times RAM if RAM is less than 1GB, and RAM if it's greater than 1GB, and that has a maximum size that's three times RAM. On Windows Vista and Server 2008, the minimum is intended to be large enough to hold a kernel-memory crash dump and is RAM plus 300MB or 1GB, whichever is larger. The maximum is either three times the size of RAM or 4GB, whichever is larger. That explains why the peak commit on my 8GB 64-bit system that’s visible in one of the screenshots is 32GB. I guess whoever wrote that code got their guidance from one of those magazines I mentioned!
    A couple of final limits related to virtual memory are the maximum size and number of paging files supported by Windows. 32-bit Windows has a maximum paging file size of 16TB (4GB if you for some reason run in non-PAE mode) and 64-bit Windows can having paging files that are up to 16TB in size on x64 and 32TB on IA64. For all versions, Windows supports up to 16 paging files, where each must be on a separate volume. 

    The full article is here:

    http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

    The WMI method your are using still works on Win7 but the initial state of the system does not create a manageable pagefile becuse it is set to the recommended system managed file.  On my Win 7 system the pagefile has never grown to be greater than the size of memory even on very heavily loaded and used systems.  Of course all systems are either 3 or 4 Gb (32 bit) or 6/8 Gb 64 bit.


    ¯\_(ツ)_/¯


    Monday, April 02, 2012 2:45 PM

All replies

  • Not necessary in Win7.

    Not necessary in XP.

    Page file will automatically be set correctly on both esystems by the default installation process.  Seetin the page file to larger than default is not usually necessary like it was on earlier versions of Windows.

    You can uyse a custom install ini file to adjust system settings without the need fo any scripts.

    New millenium, new methods.

    (acrually this has been true since the first version of Windows except for pagefile size.  I believe NT4 was the first to allow pagefile to be set in unattended.ini.

    Save yourself a lot of trouble and skip this step.

    In modern WIndows pagefile is set to 1.5 times memory and set to automatic.  It will excpand correctly and not fragment the drive as in previous versions.  The reason we used to preallocate was because the pagefile owould get split up into many bits because it was allocatred to sma;; to begin with and extended in small chinks.  Win7 aggregates teh pagfiles extensions plus all of the new disk drives are very large and the OS doesn't crowd the pagefile.

    Just besure you don't partition the disk.  TO many old duffers insist oncarving up the disk into small bits and giving them lots of drive letters.  This is done because of some mistaken idea that the disk run faster.  The exact opposite is true.

    The only legitimate reason  for partitioning the system drive is to allocate a piece to store the OS recovery image.  This puts th eimage at teh end of the drive along with oher software images which frees up teh beginning of the drive (the fastest part) to be used for the actual OS and installed software.

    NTFS is very good at managing your disk. Just run a dfreag utlity occasionally and you are set.

    (the last systemdrive I installed was 640Gb.  No need to be stingy with space here. I worked on mainfraes with far less disk space.


    ¯\_(ツ)_/¯

    Monday, April 02, 2012 3:12 AM
  • JRV,

    I appreciate your response and I agree with quite a number of your comments but not all of them and still prefer to set a static page file size. I would also never consider letting XP manage the size so that I clearly differ with you on. The beauty of this script was the fact that it was "smart" it checked how much ram you had and adjusted the size to accomodate that up to the max of 4 gig since it was written for 32 bit systems. I now only deploy x64 WIN7 so this script is useless to me.

    Since I am looking at probably 500 deployments if I cannot get the script to work then I will just let WIN7 manage it... thanks again

    Monday, April 02, 2012 11:21 AM
  • JRV,

    I appreciate your response and I agree with quite a number of your comments but not all of them and still prefer to set a static page file size. I would also never consider letting XP manage the size so that I clearly differ with you on. The beauty of this script was the fact that it was "smart" it checked how much ram you had and adjusted the size to accomodate that up to the max of 4 gig since it was written for 32 bit systems. I now only deploy x64 WIN7 so this script is useless to me.

    Since I am looking at probably 500 deployments if I cannot get the script to work then I will just let WIN7 manage it... thanks again

    It would bemush easier to use an unattended install file to set al of these things.

    Look at the MDT.  The new one allows you to manage almost everything in a config file and stil  allow custom scripts to be run during installation.  It will even jin your domain and set the OU.

    It has always been cleaner to allocate the page file duriong setup rather than after the system has started. 

    Yes - changing this script may be a waste of time with Win7 although you can still pre-allocate. The recommended method for doing WIn7 is to let WIndows manage teh page file.  This was not the case in XP.  XP alocated the file based on memory with 1.5 time memory as the upper bound.  I used to preallocate a full 1.5 initially to pervent disk fragmentation. Later XP installs I stopped this as teh defrag utilioty could aggregate the page file if it was extended.  On the newer larger disks this produced about the best performance as long as we oredered the systems with at leas 2Gb of memory. Later 4Gb was the best purchase and produced best liftime performance.  Now with Win7 64 we can just put 8Gb in to begin with and stop tuninking about memory issues.  Of course this is not the best approch for servers but works extremly well for workstations.

    I think you can be comfotable with Win7 memory defaults or use an unattended file.

    Here is a blurb from MS:

    You’ll notice that the default configuration is for Windows to automatically manage the page file size. When that option is set on Windows XP and Server 2003,  Windows creates a single paging file that’s minimum size is 1.5 times RAM if RAM is less than 1GB, and RAM if it's greater than 1GB, and that has a maximum size that's three times RAM. On Windows Vista and Server 2008, the minimum is intended to be large enough to hold a kernel-memory crash dump and is RAM plus 300MB or 1GB, whichever is larger. The maximum is either three times the size of RAM or 4GB, whichever is larger. That explains why the peak commit on my 8GB 64-bit system that’s visible in one of the screenshots is 32GB. I guess whoever wrote that code got their guidance from one of those magazines I mentioned!
    A couple of final limits related to virtual memory are the maximum size and number of paging files supported by Windows. 32-bit Windows has a maximum paging file size of 16TB (4GB if you for some reason run in non-PAE mode) and 64-bit Windows can having paging files that are up to 16TB in size on x64 and 32TB on IA64. For all versions, Windows supports up to 16 paging files, where each must be on a separate volume. 

    The full article is here:

    http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

    The WMI method your are using still works on Win7 but the initial state of the system does not create a manageable pagefile becuse it is set to the recommended system managed file.  On my Win 7 system the pagefile has never grown to be greater than the size of memory even on very heavily loaded and used systems.  Of course all systems are either 3 or 4 Gb (32 bit) or 6/8 Gb 64 bit.


    ¯\_(ツ)_/¯


    Monday, April 02, 2012 2:45 PM