Set Default Printer + VBScript

Use following script to set default printer




On Error Resume Next
Const HKCU = &H80000001
dim osh, var
dim regval, Sh, keyname
Dim objReg
Dim strcomputer


strcomputer="."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")


strKeyPath = "Software\Microsoft\Windows NT\CurrentVersion\Windows"


objReg.EnumValues HKCU, strKeyPath, arrSubKeys, arTypes
var="0"
For Each subkey In arrSubKeys
keyname = strkeypath & "\" & subkey
if (keyname = strkeypath & "\" & "Device") then
var="1" 
end If
Next

if var="0" then
objReg.SetStringValue HKCU, strKeyPath, "Device", "FACSys Fax Printer,winspool,Ne00:"
end if


Set oSH = nothing

Application Packaging Training - July 2012 Batch

Application Packaging Training new batch is scheduled to start on 30th June 2012. For further visit www.apprepack.in or contact me on Arjun@Apprepack.in

Application Packaging Training - July 2012 Batch

New batch of Application Packaging Training starting from 30th June 2012.

Duration: 1 Month

Interested candidates can visit www.apprepack.in for more information or email us on contact@apprepack.in 

-> We also deliver training on Microsoft App-V, SCCM 2007, AdminStudio, Installshield, Wise Package Studio

MSI -Installation Procedure Tables Group

The tables in the Installation Procedure group control tasks performed during the installation by standard actions and custom actions.


Some of the tables in this group control a high level action by providing a sequence of actions. Each of the following sequence tables controls a portion of a high level action.

• The InstallUISequence table
• The InstallExecuteSequence table
• The AdminUISequence table
• The AdminExecuteSequence table
• The AdvtUISequence table
• The AdvtExecuteSequence table 

MSI - Program Information Tables Group

The Program Information Tables group contain important information that used throughout the installation.

• The Property table provides a means to specify all of the properties of an installation.
• The Binary table holds the binary data for items such as bitmaps, animations, and icons. The binary table is also used to store data for custom actions. This table can contain a bitmap for a billboard, the icon for your program, or the executable form of a custom action.
• The Error table is used to look up error message formatting templates when processing errors with an error code set. This is for the usual case where there is no formatting template set. The installer has its own error processing mechanism. Errors are passed as records.
• Shortcut table the shortcut table holds the information the application needs to create Shortcuts on the user's computer.
• The ReserveCost table contains the disk space necessary for each component to work properly. 

MSI - Locator Tables Group

The Locator Tables group is used to locate files and applications. To search for a file, first determine the file signature and then locate the file. The Locator tables are used to search the registry, installer configuration data, directory tree, or .ini files for the unique signature of a file. The file signature can then be checked in the Signature table to ascertain that a particular file is really the file being sought and not another file with the same name. If a record in a locator table does not contain a key into the Signature table, then the record refers to a directory and not a file.


The component controlling a file is found in the File table through the external key to the Component table. The installer resolves the location of a file through the Component table because every file belongs to one component. The location of a component is found through an external key in the Component table to the Directory table.


The location of an application is found by searching for files that make up the application. The installer also provides two tables for searching for previous versions of an application: the AppSearch table and the CCPSearch table.


The following tables make up the Locator tables group and are used to determine the file signature.

• The RegLocator table holds the information needed to search for a file or directory in the registry.
• The IniLocator table holds the information needed to search for a .ini file. The .ini file must be present in the default Microsoft® Windows® directory.
• The CompLocator table holds the information needed to search for a file or a directory using the installer's configuration data.
• The DrLocator table holds the information needed to search for a file or directory in the directory tree.
• The AppSearch table contains the properties that must be set to the search result of a corresponding file signature.
• The CCPSearch table contains the list of file signatures, at least one of which needs to be present on a user's computer for the Compliance Checking Program (CCP).

MSI - System Tables Group

The tables of the system tables group track the tables and columns of the installation database.

• The _Tables table tracks all the tables in the database. This includes tables that you may have created for your own custom actions. Query this table to find out if a table exists.
• The _Columns table tracks columns in the installation database. Temporary columns are currently not tracked by this table. Query this table to find out if a given column exists.
• The _Streams table lists embedded OLE data streams.
• The _Storages table lists embedded OLE data storages.
• The _Validation table. The _Validation table tracks the types and allowed ranges of every column in the database. The _Validation table is used during the database validation process to ensure that all columns are accounted for and have the correct values. This table is not shipped with the installer database. 

MSI - Registry Tables Group

The installer has specific tables for the different types of registry entries. When populating the registry tables group it is important to try to minimize the number of entries put into the Registry table and maximize the use of the other, specific, registry tables. This is because the installer cannot distinguish between different types of registry entries in the Registry table and cannot use the internal logic necessary to take full advantage of all of the installer features, such as advertising. Authoring COM and shell-related registry entries in this way also provides a more logical organization and can help minimize erroneous registration of COM server information.


The registry entry group contains the following tables of specific registry entries.

• The Extension table contains all of the filename extensions your application uses along with their associated features and components.
• The Verb table associates command-verb information with the file extensions listed in the Extension table. This provides an indirect link between the Verb and Feature table that is needed for feature advertisement.
• The TypeLib table provides information that the installer places in the registry for the registration of type libraries. Type library entries are not written at the time of advertisement. The installer writes the type library entries at the time the components associated with the library are installed.
• The MIME table associates a MIME context type with a CLSID or a file extension. This provides a path between the MIME and Feature Table that is needed for feature advertisement.
• The SelfReg table provides information needed to self-register modules. Self-registration is provided by the installer only for backward compatibility and it is not recommended as a method for populating the registry, however if there are any modules in your application that must register themselves, use the SelfReg table.
• The Class table is used to register Class IDs and other information for COM objects. This table contains COM server-related information that must be generated as a part of the product advertisement.
• The ProgId table associates program IDs with class IDs.
• The AppId table is used to register common security and configuration settings for DCOM objects.
• The Environment table is used to set the values of environment variables, and in Windows NT/Windows 2000 the Environment table writes to registry as well.
• The Registry table holds any other information that the application needs to put into the system registry. This would include default settings, user information or data, or COM registration not supported by the above tables.
• The RemoveRegistry table contains the registry information the application needs to delete from the system registry at installation time.      

MSI - File Tables Group

An installer package developer should consider populating the file table group of tables after breaking the application into components and features and after populating the core tables group. The file table group contains all of the files belonging to the installation and most of these files are listed in the File table. The Directory table is not listed in this group, but is closely related to the file table group. The Directory table gives the directory structure of the installation.


The file group of tables contains all of the tables that are related to files.

• The File table lists files belonging to the installation. Files that are not listed in the File table include disk files, which are listed in Media table. Because every file belongs to a component, the File table has an external key into the Component table.
• The RemoveFile table contains a list of files to be removed by the RemoveFiles action.
• The Font table lists font files to be registered with the system.
• The SelfReg table lists module files of the installation that are self-registered.
• The Media table lists the source media and disks belonging to the installation.
• The BindImage table lists files that are bound to DLLs imported by executables.
• The MoveFile table specifies which files are moved during the installation.
• The DuplicateFile table specifies which files are duplicated during the installation.
• The IniFile table lists the .ini files and the information that the application needs to set in the file.
• The RemoveIniFile table contains the information an application needs to delete from a .ini file.
• The Environment table is used to set the values of environment variables and in Windows 95, the Environment table lists changes that will be made to the autoexec.bat file.
• The Icon table provides icon information that is copied to a file as a part of product advertisement.

MSI Core Tables Group

The core group consists of tables describing the fundamental features and components of the application and the installer package. Developers of install packages should therefore consider how to populate these tables first because the organization of much of the database will become apparent from the content of this group.

• The Feature table lists all features belonging to the application.
• The Condition table contains the conditional expressions that determine whether or not a particular feature will be installed.
• The FeatureComponents table describes which components belong to each feature.
• The Component table lists all components belonging to the installation.
• The Directory table lists the directories that are needed during the installation. Because each component must be associated with one and only one directory, the Component table is closely related to this table and has an external key to the Directory table.
• The PublishComponent table lists the features and components that are published for use by other applications. Components and Features are the two types of feature advertisement. 

Enable MSI logging

Set following registry to enable MSI logging




The new log's file name is random, but begins with the letters "MSI" and end with a .log extension will be created in %temp% folder

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Reg_SZ: Logging

Value: voicewarmup 

Why Windows Installer prompting for a reboot

Windows Installer may prompt for a reboot if it installs over a file that is in use or the package explicitly requests that the installer reboot. It is easy to determine if Windows Installer prompts for a reboot because it installed over a file that is in use. The first step is to generate a verbose log file. In the verbose log file, look for the presence of the ReplacedInUseFiles property in the property dump. If this property is present with a value of 1, then the Installer will require a reboot because it overwrote an in-use file.

Processing Options in the Custom Actions

1. Synchronous:
 Windows Installer runs the custom action synchronously to the main installation. It waits for the custom   action to complete successfully before continuing the main installation.


2. Synchronous, ignore exit code 


Windows Installer runs the custom action synchronously to the main installation. It waits for the custom action to complete before continuing the main installation; the action can be either success or fail.


 3. Asynch, wait at end of sequence 


Windows Installer runs the custom action simultaneously with the main installation. At the end it waits for the exit code from the custom action before continuing.


 4. Asynch, no wait 


Windows Installer runs the custom action simultaneously with the main installation. It doesn’t wait for completion of the custom action and doesn’t check the exit code also.

Limitations of App-V

1. Device Driver: Microsoft Application Virtualization does not support sequencing of device drivers thus any application which install device driver should not be sequenced.

2. Application Size: If the maximum client cache size is set for 2 GB (The max can be 64 GB), then the maximum size of application (sft file) which can be streamed on that machine is 2 GB. All applications which have the installed footprint greater than or equal to the max client size, set by the client, should not be sequenced. Also the Max application size App-V can handle is 4GB, [Q: drive has FAT file type and the max file size FAT can handle is 4GB]. 

3. Shortcuts: Application should have minimum of one shortcut. If no shortcuts are present then the application should be sequenced in a suite along with the application which needs it. For example if Macromedia Flash is the application in question to be sequenced then the shortcut should be pointing to the locally installed Internet Explorer

4. Middleware: Middleware applications are not a good candidate for sequencing as they can be used as a prerequisite by multiple applications, thus should be installed locally. but if multiple version of it are needed then they should be sequenced along with the application which needs them. It is always advised to have only one version of any application/middleware in the organization thus conditions for multiple versions should be avoided With Version 4.5 most of the middle-wares can be sequenced and used as secondary packages.

5. Path hard coding: The application should not have folder/file path hard coding in the application itself. Some application hard code the path of files in registry or ini file or executable. In these cases it has been found that they can be sequenced most of the time using VFS sequencing method, but extreme care should be taken while sequencing & testing these applications. Also Configuration files such as ini, conf, txt, registries etc are good places to look for the hard coding

6. Base Build Applications: Applications which are already part of base build should not be sequenced. One can sequence them but they are of no real value as they will already be present on the client machines

7. Auto Update: Application with automatic updates should not be sequenced. Sequenced application most of the time fails to properly update itself. Also allowing auto update leads to non compliance of application version. These types of applications should only be sequenced if the auto update feature can be disabled during sequencing procedure

8. Services: Services which can be started when application starts and shuts down when application main executable shuts down can be included in sequence. Services that run as their own (like boot-time services do but there are others also) are not suitable for sequencing since under App-V all application starting happens under user’s session context.  Also applications which install services which run using specific user credentials cannot be sequenced

9. COM+: Some application which uses COM+ might not work properly in virtual environment, thus this type of applications needs be tested properly

10. COM DLL: Few application which uses COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe, does not work properly in App-V Environment. Thus this type of applications needs be tested properly

11. Licensing Policies: Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address, username etc. It should not be sequenced if activation cannot be done by the user at the first launch 2009 c Mayank Johri Microsoft Application Virtualization - An Introduction to Sequencing Source Files Validation 10 of sequenced application

12. Internet Explorer & Service Packs: Internet Explorer, Windows service patches and service packs cannot & should not be sequenced

13. Network Share Application: It is not a good practice the run applications from network share as they tend to violate the enterprise desktop integrity and thus known to cause integration issues. It is advised to have to entire application inside of App-V package

14. Hosts file located in “%windir%\system32\etc” cannot be sequenced and should be updated on local machine before the sequenced application is launched

LOCAL INTERACTION ALLOWED attribute in OSD

Allows the virtual application to work as local installed application

What is VFS Sequencing or local drive sequencing

In VFS sequencing the application and its supporting applications are installed in there default location. 

Benefits: 

          Applications with hard-coded path entries can only be sequenced using this method.

Drawbacks

·         Sequenced applications run slightly slower then Q Drive based sequence

·         Some applications might not work properly, especially apps which try to            evaluate the launch location at the launch time.

Extract the Binary from the Binary Table

1. Browse to Binary Table
2. Double click the data part of the binary which is to be extracted
3. Select option  "Write Binary data to file" depending
4. Provide the file location to be extracted in file name tab
5. select OK


We will get the extracted file in the desired location.

Get System Information - VBScript

Set oSystemSet = GetObject("winmgmts:").InstancesOf("Win32_ComputerSystem")


For Each oSystem in oSystemSet


 system_name = oSystem.Caption 
 system_type = oSystem.SystemType
 system_mftr = oSystem.Manufacturer
 system_model = oSystem.Model
Next


Set oProcSet = GetObject("winmgmts:").InstancesOf("Win32_Processor")


For Each oSystem in oProcSet
 proc_desc = oSystem.Caption 
 proc_mftr = oSystem.Manufacturer
 proc_mhz = oSystem.CurrentClockSpeed
Next


Set oBiosSet = GetObject("winmgmts:").InstancesOf("Win32_BIOS")


For Each oSystem in oBiosSet
      bios_info = oSystem.Version
Next


Set oZoneSet = GetObject("winmgmts:").InstancesOf("Win32_TimeZone")


For Each oSystem in oZoneSet
      loc_timezone = oSystem.StandardName
Next


Set oOSSet = GetObject("winmgmts:").InstancesOf("Win32_OperatingSystem")


For Each oSystem in oOSSet


 os_name = oSystem.Caption
 os_version = oSystem.Version
 os_mftr = oSystem.Manufacturer
 os_build = oSystem.BuildNumber
 os_dir = oSystem.WindowsDirectory
 os_locale = oSystem.Locale
 os_totalmem = oSystem.TotalVisibleMemorySize
 os_freemem = oSystem.FreePhysicalMemory
 os_totalvirmem = oSystem.TotalVirtualMemorySize
 os_freevirmem = oSystem.FreeVirtualMemory
 os_pagefilesize = oSystem.SizeStoredInPagingFiles


Next


sMsg = ("OS Name:  " & os_name & Chr(10))
sMsg = sMsg & ("Version:  " & os_version & " Build " & os_build & Chr(10))
sMsg = sMsg & ("OS Manufacturer:  " & os_mftr & Chr(10))
sMsg = sMsg & ("oSystem Name:  " & system_name & Chr(10))
sMsg = sMsg & ("oSystem Manufacturer:  " & system_mftr & Chr(10))
sMsg = sMsg & ("oSystem Model:  " & system_model & Chr(10))
sMsg = sMsg & ("oSystem Type:  " & system_type & Chr(10))
sMsg = sMsg & ("Processor:  " & proc_desc & " " & proc_mftr & " ~" & proc_mhz & "Mhz" & Chr(10))
sMsg = sMsg & ("BIOS Version:  " & bios_info & Chr(10))
sMsg = sMsg & ("Windows Directory:  " & os_dir & Chr(10))
sMsg = sMsg & ("Locale:  " & os_locale & Chr(10))  
sMsg = sMsg & ("Time Zone:  " & loc_timezone & Chr(10))
sMsg = sMsg & ("Total Physical Memory:  " & os_totalmem & "KB" & Chr(10))
sMsg = sMsg & ("Available Physical Memory:  " & os_freemem & "KB" & Chr(10))
sMsg = sMsg & ("Total Virtual Memory:  " & os_totalvirmem & "KB" & Chr(10))
sMsg = sMsg & ("Available Virtual Memory:  " & os_freevirmem & "KB" & Chr(10))
sMsg = sMsg & ("Page File Space : " & os_pagefilesize & "KB" & Chr(10))


MsgBox sMsg, 0,"System Summary Information"

Get Serial Number of Operating system Installed - VBScript

Set SNSet = GetObject("winmgmts:").InstancesOf ("win32_OperatingSystem")


for each SN in SNSet
MsgBox "The serial number for the installed OS is: " & SN.SerialNumber
Next

Get Operating System installed on a machine

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
    ("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
    Wscript.Echo objOperatingSystem.Caption & " " & _
        objOperatingSystem.Version
Next

Get ComputerName and Username - VBScript

Set oNetwork = CreateObject("WScript.Network")
sUserName = oNetwork.UserName
sComputerName = oNetwork.ComputerName
MsgBox("UserName = " & sUserName & vbCRLF & "ComputerName = " & sComputername)

Get IP Address of machine - VBScript

On Error Resume Next
Dim IPADDRES 
Dim WshShell 


strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colNicConfigs = objWMIService.ExecQuery _
 ("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True")


Set WshShell=CreateObject("WScript.Shell")


For Each objNicConfig In colNicConfigs
      For Each strIPAddress In objNicConfig.IPAddress
             IPADDRES = strIPAddress
      Next
Next


msgbox IPADDRES


Set WshShell = Nothing
WScript.Quit

Create Text file and write lines using VBScript

Following script will create sample.txt file in the location where this script is stored and 10.10..10.93 will be written to sample.txt file




Dim objWshShell, objFSO, sScriptDir
Set objWshShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")


sScriptDir=objFSO.GetParentFolderName(WScript.ScriptFullName)
strSecFileName = sScriptDir & "\sample.txt"


Set objSecFile = objFSO.CreateTextFile(strSecFileName, True)
objSecFile.WriteLine("10.10.10.93")


Set objFSO = Nothing
Set objWshShell = Nothing

Change File Attributes - VBScript

use following script to change attributes of any file or folder.
options are normal, read-only, hidden and system.
any combination of attributes may be set.


Dim FSO, fil, f, attr, i, Arg
Set FSO = CreateObject("Scripting.FileSystemObject")


  '--check for drag-and-drop:
   
     If WScript.arguments.count = 0 Then
           Arg = InputBox("Enter the path of the file or folder you want to change the attributes of.", "Change File Attributes")
     Else
           Arg = WScript.arguments.item(0)
     End If


If Arg = "" Then WScript.quit




  '--check for existence of either file or folder and keep track of which with i :


If FSO.FileExists(Arg) = True Then   
  f = "File" 
  i = 1
ElseIf FSO.FolderExists(Arg) = True Then
  f = "Folder"
  i = 2  
Else
  MsgBox "Path is wrong. No such file or folder.", 16, "Wrong Path"
  WScript.quit
End If


attr = InputBox("Enter the attributes number. Add numbers to get the desired combination of attributes." & VBCrLf & "Normal is 0" & VBCrLf & "ReadOnly is 1" & VBCrLf & "Hidden is 2" & VBCrLf & "System is 4", "Choose Attributes Setting", "0")


'--make sure that input is a number from 0 to 7:


If isNumeric(attr) = False Then
    MsgBox "Wrong entry. Must be a number from 0 to 7.", 16, "Wrong Number"
    WScript.quit
End If
If cInt(attr) > 7 or cInt(attr) < 0 Then
    MsgBox "Wrong entry. Only 0 to 7 are possible.", 16, "Wrong Number"
    WScript.quit
End If


  If i = 1 Then
     Set fil = FSO.GetFile(Arg)
     fil.attributes = attr
     Set fil = Nothing
     MsgBox f & " attributes changed.", 0, "All Done"
  End If
  If i = 2 Then
     Set fil = FSO.GetFolder(Arg)
     fil.attributes = attr
     Set fil = Nothing
    MsgBox f & " attributes changed.", 0, "All Done"
 End If

Increment ActiveSetup Version - VBScript

'This script will create the Active setup if not present on the system, otherwise it will increment the version of the active setup 


' Need to replace the "Any that you want to run" with the exact path of the EXE/MSI/Script which has to run
' Replace the "<NameOfActiveSetup>" with the related unique application name




Option Explicit
On Error Resume Next
Dim WshShell ,PrgFiles,KeyValue
Set WshShell=CreateObject("WScript.Shell")




KeyValue=WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\<NameOfActiveSetup>\Version")


WshShell.RegWrite "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\<NameOfActiveSetup>\StubPath", "Any that you want to run"


'Err.Clear


If  Err.Number=0 Then
     
WshShell.RegWrite "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\<NameOfActiveSetup>\Version",KeyValue+1,"REG_SZ"   

Else

WshShell.RegWrite "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\<NameOfActiveSetup>\Version","1","REG_SZ"

End If




Set WshShell = Nothing
Set PrgFiles = Nothing


WScript.Quit

Get current directory - VBScript

on Error Resume Next


Set objWshShell = CreateObject("WScript.Shell")
Set objFileSystem = CreateObject("Scripting.FileSystemObject")

sScriptDir=objFileSystem.GetParentFolderName(WScript.ScriptFullName)


msgbox sscriptdir

Hide ARP Entry of MSI

use following script to Hide ARP entry of an MSI



Dim WSHShell,strRegKey 
Set WSHShell = WScript.CreateObject("WScript.Shell") 
WSHShell.Regwrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode>\SystemComponent","1","REG_DWORD"

Check Free Disk Space - VBScript

strComputer = "." 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_LogicalDisk WHERE DeviceID = 'C:'",,48) 
For Each objItem in colItems 
    Bytes = objItem.FreeSpace


If Bytes >= 1073741824 Then
SetBytes = Round(FormatNumber(Bytes / 1024 / 1024 / 1024, 2), 0) & " GB"
ElseIf Bytes >= 1048576 Then
SetBytes = Round(FormatNumber(Bytes / 1024 / 1024, 2), 0) & " MB"
ElseIf Bytes >= 1024 Then
SetBytes = Round(FormatNumber(Bytes / 1024, 2), 0) & " KB"
ElseIf Bytes < 1024 Then
SetBytes = Bytes & " Bytes"
Else
SetBytes = "0 Bytes"
End If


Wscript.Echo "OUTPUT = " & SetBytes


Next

SendKeys VBscript Example

On Error Resume Next
Set WshShell = CreateObject("WScript.Shell")
strWindowNameEN = "PictureTaker Personal Edition"


successEN = False
Do
successEN = WshShell.AppActivate(strWindowNameEN)
Loop Until (successEN = True)
If (successEN) Then
WshShell.AppActivate strWindowNameEN
End IF


WshShell.SendKeys "{TAB}"
WshShell.SendKeys "{ENTER}"

Install MSI using WiseScript

Following script installs sample.msi located in the location where wisescript EXE is located.


Declaration of Variables
-> Set Variable MSI to "Path of MSI"
-> Set Variable MSIEXEC to "path of msiexec.exe file present in system32 folder"


then execute MSI installation command


-> Execute Program, provide the executable to run along with command line arguments

-> Ouput WiseScriptEXE needs Sample.msi to be present beside to perform MSI installation

Delete Registries using Wise Script

Deleting registries along with hive using WiseScript.


-> Use the function, "Edit Registry" and import the registry that needs to be deleted


-> Under Operation, Select "Remove Key and all sub Keys" for any registry under that hive


-> In the following example, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator and all registry keys under Communicator will be deleted using following script.

Kill Process using Wise Script

Change ProcessName.exe to whatever process to be killed

AdminStudio 11 Download

Latest version Adminstudio 11 can be downloaded using following URL

http://www.flexerasoftware.com/resources/trials.htm#adminstudio

New Installshield 2012 Spring Features

Show All

	Premier	Professional	Express
Hybrid Cloud Deployments New Microsoft® SQL Azure™ database scripting capabilities enable hybrid cloud SQL deployments. More
Pre-Release Support for Microsoft® Windows® 8 and Windows Server® 2012 InstallShield 2012 Spring includes support for Microsoft Windows 8 and Windows Server 2012.More
Microsoft® Visual Studio® 11 Support InstallShield 2012 Spring includes support for Microsoft Visual Studio 11. More
Advanced Wizard Page Editor and Redesigned Wizard Pages InstallShield 2012 Spring provides an entirely new end-user interface with redesigned built-in wizard pages and a new wizard page editor. More
Automatic Checking for Installer Updates and Patches InstallShield 2012 Spring automatically checks and downloads updates and patches at run-time. More
Suite Installation Enhancements Enhanced InstallShield 2012 Spring Suite/Advanced UI project type provides more capabilities to bundle multiple products together into a single, unified suite installation. More
Microsoft® System Center 2012 Configuration Manager Support InstallShield 2012 Spring enables Software Producers to provide required deployment metadata to their Enterprise customers. More
PowerShell Support InstallShield 2012 Spring enables Software Producers to streamline installation scripting requirements. More

• 
  

Windows Intune

Windows Intune simplifies and helps businesses manage and secure PCs using Windows cloud services and Windows 7 Enterprise — so your computers and users can operate at peak performance from virtually anywhere. With cloud services, you get a comprehensive desktop solution with a low up-front investment and predictable (monthly, per PC) billing that helps keep your finances under control. Windows Intune licensing also includes upgrade rights to the latest versions of Windows client operating system. Together Windows Intune and Windows 7 Enterprise help businesses improve end-user productivity and optimize IT labour costs.

Differences between Windows To Go and Typical Windows Installation

Windows To Go operates just like any other installation of Windows with a few exceptions. These exceptions are:

• Hibernate and sleep are disabled by default. To help prevent Windows To Go from accidental data corruption during roaming hibernate and sleep are disabled. They can be re-enabled by using Group Policy settings.
  
• Internal disks are offline. To ensure data isn’t accidentally disclosed, internal hard disks on the host computer are offline by default when booted into a Windows To Go. Similarly if a Windows To Go drive is inserted into a running system the Windows To Go drive will not be listed in Windows Explorer.
  
• Trusted Platform Module (TPM) isn’t used. When using BitLocker Drive Encryption a pre-operating system boot password will be used for security rather than the TPM since the TPM is tied to a specific computer and Windows To Go drives will move between computers.
  
• Windows Recovery Environment isn’t available. In the rare case that you need to recover your Windows To Go drive, you should re-image it with a fresh image of Windows.
  
• Push Button Reset isn’t available. Resetting to the manufacturer’s standard for the computer doesn’t really apply when running Windows To Go, so the feature was disabled.

Windows To Go

Windows To Go is a feature in Windows 8 Enterprise that allows Windows 8 Enterprise to boot and run from USB mass storage devices such as flash drives and external hard drives. It is a fully manageable corporate Windows 8 environment.

It is intended to allow enterprise administrators to provide users with an imaged version of Windows 8 that reflects the corporate desktop and as such is aimed at enterprises.