We encountered the same problem.
We found a kind of workaround by packaging a batch file launching "reg import file.reg" as a 64bit application (there's a checkbox for that in the package configuration).
The problem with this workaround is that the agent must be installed with the software distribution component before trying to install the package, that is before removing autologon information.
The reg file I use works and contains the following :
Windows Registry Editor Version 5.00
Currently, provisioning is a 32bit application and doesn't take into account the 64bit section of the registry. You will need to use workarounds such as the one described above to deal with these issues until there is an update.
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
Maybe there is something to build around that idea : http://stackoverflow.com/questions/1229760/how-do-i-read-64-bit-registry-values-from-vbscript-running-as-a-an-msi-post-inst .
The principle would be to use WMI to get access to the 64 registry from a script in the 32bit environment.
1 of 1 people found this helpful
Autoit handles this very easily - regread/regwrite:
When running on 64-bit Windows if you want to read a value specific to the 64-bit environment you have to suffix the HK... with 64 i.e. HKLM64.
As Zman has said AutoIT handles this very easily. You can create a script with the following (I've taken this from a script I have used);
Main() Func Main() RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup", "DisableMonitoring", "REG_DWORD", "1") EndFunc
You are then able to either add this in LANDesk as a Software Disitrubtion task and call that from the provisioning template, or copy the .exe to the machine using the 'Copy File' action and then execute it using the 'Execute File' action.
If you are using Autoit, depending on whether you install AutoIT / Scite on a 64bit machine or a 32bit machine, your default wrapper settings are set to a specific Architecture. You can specify what Arch. you want your wrapper to deploy with by using the Autoit Directives #AutoIt3Wrapper_UseX64=x.
This can have an effect on how to write your registry.
If you use 64-bit wrapper (#AutoIt3Wrapper_UseX64=Y)
Then you can use the normal HKLM to write to the 64-bit registry
If you are using the 32-Bit wrapper (#AutoIt3Wrapper_UseX64=N)
Then you have to use the HKLM64 as Zman referenced to get into the 64-bit registry
You might also be able to use the special Sysnative alias. It allows 32bit apps to skip past the File System Redirector and get to the 64bit versions of apps. For more info see: File System Redirector
So you could try something like running %windir%\Sysnative\reg.exe. Make sure it is %%windir%% in the template
This issue needs to be corrected. this is going to cause a lot of problems for us as our customer has selected Win7 x64 as their new OS and we are re-engineering our imaging and build process including provisioning. what good is a tool that needs to set registry values in order to work properly (AutoAdminLogon enabled) when it cannot set those registry values? Can this be overcome by setting AutoAdminLogon in sysprep? Is this issue being worked on and possible to be addressed in the next release?
You can set the auto login in the unattend.xml file and shat should address your current issue.
This is something we are already doing but we do not want to deal with the logon count.
You can or do something like this:
$OSArch = @OSArch
Case $OSArch = "X86"
$HKVar = ("HKEY_LOCAL_MACHINE\SOFTWARE\")
Case $OSArch = "X64"
$HKVar = ("HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\")
Either way LANDesk needs to start embracing the X64 world better.
if we are referring to autoit,
I do it like this (but either will work)
If @OSArch = "X64" Then
$x64reg = RegRead("HKLM64\Software\..)
$x86reg = RegRead("HKLM\Software\..)
agreed that LANDesk should treat it better. In Provisioning it would be nice to see different target OS options: Windows 7 (both), Windows 7 x86 and Windows 7 x64.
and by choosing the Target OS the actions would adjust accordingly, however still would like to see options in the actions that could specify. For example in the update registry you would have a check box that said "64-bit Registry Hive"
I use the variable $HKVar since I can then use it as a universal prefix
$VulscanPendingFile = RegEnumVal($HKVar & "\LANDesk\ManagementSuite\WinClient\VulscanReboot",$i)
See tired, burnt out, overworked minds thing alike.
We're on LD 9.6 SP1 (march component patch) and this is still an issue. Is the only workaround really to go outside the native provisioning options?