PerUser vs PerMachine Installation

There is a MSI property that can be placed within the application package that allows the application setup to announce to Windows Installer that it wants to be installed “Per-User”.

Windows XP

The ALLUSERS MSI property can be set so that the application package will be run in the “Per-User” context. Both by the absence of the ALLUSERS property or the property is present but the value is set to NULL (ALLUSERS=”") will force the installation package to be run in the “Per-User” context.

Vista

On Vista, you could still force the installation package to be run as “Per-User” as we have discussed. Note that the user’s privileges are immaterial when running in the “Per-User” context – but once the decision is made that the install will be run in the “Per-User” context (By setting the ALLUSERS=”" or not having the property), the User rights issue makes no difference. But remember, the install starts but it WILL FAILif the user doesn’t have Admin rights and the install tries to write to any machine-wide resources.

If a user has Admin rights, but the install is run in the “Per-User” context, with the Admin rights, any accidental writing to machine-wide resources will be allowed.

Windows 7

On Windows 7, the ability to run as “Per-User” is constrained by the specifics of the package. Essentially these points are important for an application setup to be eligible for a “Per-User” installation context:

• All files are installed to Per-User folders, such as
  • “C:\Documents and Settings\$User\Local Settings\Application Data” on WinXP
  • “C:\Users\$User\AppData\Roaming” on Windows 7
• All Shortcuts and the Add/Remove Control Panel entry are only seen by that user
• All registry entries (Application data and registration) are made to HKEY_CURRENT_USER hive.
• No registry entries are made to machine-wide registry keys, such as HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT hives
• The installation package cannot allow the user performing the installation package to select destination directories that are machine-wide, such as “c:\Program Files”
• All application binary file (EXE, DLL) need to be digitally signed to be allowed to be installed by “Per-User” for Windows 7.

On Windows 7, if any of the above constraints are not met, the package will be installed “Per-Machine” – this means that a “Per-User” will not be allowed!

Self Healing Explanation

XCACLS Command line syntax

Xcacls.exe syntax


xcacls file name [/T] [/E] [/C] [/G user:perm;spec] [/R user] [/P user:perm;spec [...]] [/D user [...]] [/Y]
where file name indicates the name of the file or folder to which the ACL or access control entry (ACE) is typically applied. All standard wildcard characters can be used.

/T recursively walks through the current folder and all of its subfolders, applying the chosen access rights to the matching files or folders.

/E edits the ACL instead of replacing it. For example, only the administrator will have access to the Test.dat file if you run the XCACLS test.dat /G Administrator:F command. All ACEs applied earlier are lost.

/C causes Xcacls.exe to continue if an "access denied" error message occurs. If /C is not specified, Xcacls.exe stops on this error.

/G user:perm;spec grants a user access to the matching file or folder.
·       The perm (permission) variable applies the specified access right to files and represents the special file-access-right mask for folders. The perm variable accepts the following values:
o       R Read
o       C Change (write)
o       F Full Control
o       P Change Permissions (special access)
o       O Take Ownership (special access)
o       X EXecute (special access)
o       E REad (Special access)
o       W Write (Special access)
o       D Delete (Special access)
·       The spec (special access) variable applies only to folders and accepts the same values as perm, with the addition of the following special value:
o       T Not Specified. Sets an ACE for the directory itself without specifying an ACE that is applied to new files created in that directory. At least one access right has to follow. Entries between a semicolon (;) and T are ignored.

Notes
§       The access options for files (for folders, special file and folder access) are identical. For detailed explanations of these options, see the Windows 2000 operating system documentation.
§       All other options, which can also be set in Windows Explorer, are subsets of all possible combinations of the basic access rights. Because of this, there are no special options for folder access rights, such as LIST or READ.

/R user revokes all access rights for the specified user.

/P user:perm;spec replaces access rights for user. The rules for specifying perm and spec are the same as for the /G option. See the "Xcacls.exe examples" section.

/D user denies user access to the file or directory.

/Y disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine stops responding until the right answer is entered. The /Y option was introduced to avoid this confirmation, so that Xcacls.exe can be used in batch mode.

Setup.exe Silent Switches

Perhaps there is some undocumented process you can uncover. Below are some command lines found to work, try "setup.exe /?" first then go through the list below- you may get lucky!

• setup.exe /q
• setup.exe /qn
• setup.exe /silent
• setup.exe /s
• setup.exe /NoUserInput
• setup.exe /unattended
• setup.exe /CreateAnswerFile
• setup.exe /quiet
• setup.exe /passive
• setup.exe /NoUI
• setup.exe -s
• setup.exe -silent
• setup.exe /VerySilent
• setup.exe -r      (Creates response file in Windows directory with name setup.iss)

What is SystemGuard

SystemGuard tracks and analyses configuration repositories and resources used by the application and intercepts the use of these resources, redirecting them to the virtualized instances of the resources.


The Microsoft App-V Application Virtualization Platform‘s heart is SystemGuard, a patented technology which enables applications to run without installing them locally—and without altering the client‘s operating system.


SystemGuard eliminates common application deployment and management problems:


Application Conflicts: Almost any application will run on any client at any time.


Version Incompatibilities: Different versions of the same application will run simultaneously on the same computer.


Multi-User Access: Applications that were previously unable to run in multi-user mode and therefore could not run within Citrix MetaFrame or Windows Terminal Services, will now do so and function correctly for multiple users.


Multi-Tenancy Issues: Instances of the same application using different database paths will run on the same computer at the same time.


Server Siloing and N-Way Regression Testing: The need for many separate server farms and time-intensive regression testing for application conflicts is eliminated.

Check if Registry hive exists

Following script checks if HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft hive exists


const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."


Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
strComputer & "\root\default:StdRegProv")


strKeyPath = "SOFTWARE"
oReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys


For Each subkey In arrSubKeys


    If subkey = "Microsoft" Then
   Exit For
     End If
Next


    MSGBOX subkey

ThinApp MSI Generation Template

In the Vmware ThinApp folder you will find the file Template.msi. You can customize this template to ensure the .msi files generated by ThinApp adhere to company deployment procedures and standards. For example, you can add registry settings that you want ThinApp to add to client computers as part of the installation.

Can ThinApp MSIs be installed by Regular Users

Of course!

Simply put, the MSI settings are straight form Microsoft Installer requirements, and the PACKAGE.INI file only shows those specific settings pertaining to a virtualized application. Remembering the four things which occur during a ThinApp package registration (either through the SDK, THINREG, or a ThinApp MSI), they are...

1. Shortcut Creation on the desktop, start menu, or elsewhere (taskbar or quick launch bar).
2. File Type Association so when a user double-clicks on a file associated to the virtualized app, the virtualized application starts and opens the file.
3. Protocol Association, so when a user clicks on a link with an associated protocol (i.e. HTTP, HTTPS, FTP, MAILTO, NOTES, etc.) the appropriate virtualized application opens and conducts the associated action with that protocol.
4. COM Object Association, so when a user initiates an action with an associated object the appropriate virtualized application opens and conducts the associated action with the object.

The registration process just assigns these items to the user or system based upon the commands within the registration process. For THINREG, using a "/A" switch tells ThinApp to assign the aforementioned four items within the application to the entire system (by default, THINREG only registers these for the user).

The same goes for MSI settings, however, it's default is to register the virtualized app to the entire system due to the default settings below:

• MSIDefaultInstallAllUsers=1
• MSIRequireElevatedPrivileges=1

Changing the above settings to "0" will allow the MSI to be installed by a regular user and only register the components to the user executing the MSI.

• MSIDefaultInstallAllUsers=0
• MSIRequireElevatedPrivileges=0

NOTE: Don't forget to save the PACKAGE.INI and rebuild with BUILD.BAT.

So now, not only will your apps run under regular user permissions, but they can also be installed and uninstalled by regular users! This means, you can remove Local Admin permissions and reduce your overall desktop security risks!

VMWare ThinApp Factory Released

ThinApp Factory is a virtual appliance which can be used to automate the packaging of legacy Windows applications with VMware ThinApp.

The virtual appliance is a Debian Linux vApp which can be installed on VMware vSphere 4.1 or higher or VMware Workstation 8.x and higher. It has a TomCat web based interface and built into it is an enhanced ThinApp package editor and basic web based store for users to install their own applications.

It can pull from manually uploaded installers, regular file share repositories (something very common amongst IT shops), as well as RSS-style app-installer feeds using the JSON format.

For more information on ThinApp Factory, please visit vmware blog 

http://blogs.vmware.com/thinapp/2012/06/thinapp-factory-released.html

Migration from SCCM 2007 to SCCM 2012

Please check following video on Microsoft Technet

http://technet.microsoft.com/en-us/video/Video/hh304354

MountPoint vs VFS Sequencing

There are two ways you can sequence an application. They are Mount point sequencing and VFS  sequencing .
                                                                  

Mount Point Installation

                Installing an application to a folder in Mount point is considered to be an efficient way of sequencing application. A deeper look at the scanning operation performed during the sequencing operation would help us better comprehend the advantages of mount point installation.

·      
As the application is installed to a mount point (Q:\), only required files are monitored by the sequencer. The tax on the sequencer to scan the entire C:\ is hugely removed in this case there by making it easily the efficient way to sequence an application.

VFS Installation

            Nonetheless, there are applications which refuse to install to a location other than C:\ (Virtual File System). Under these circumstances, the entire hard disk is scanned for system changes, making it much slower than mount point installation. Also, scanning the entire hard disk for changes would result in capturing files that are not actually used by the application.

From the above points, it is evidently visible that Mount point installation is the preferred method to sequence an application compared to VFS installation

AppV Security Descriptor

By enabling Security Descriptors during sequencing an application, permissions on the windows file system are “pulled into the bubble”. The sequencer always captures security descriptors during sequencing, but only with the Enforce Security Descriptors setting checked, the client enforces them on the file system drive at runtime.

So if a users group on the Sequencer had read rights on the T:\APP-X folder, these rights are stored in the Virtual Environment. Once streamed and run on the client, the user cannot edit in this specific folder. In this manner you can set permissions on parts of the Virtual Environment and secure parts of being modified by a user

   

On the contrary, I would check this option ONLY when it is absolutely essential. Meaning, only for badly written software which expects specific security settings for proper functionality would precisely be the circumstances under which I would keep the option checked. When the security descriptors are turned off, the user is considered to have full rights on the asset directory which would be the ideal case.

    

USEFUL TIP you can turn off “Enforce Security Descriptor” by default by editing the “Default.sprj” file.

Open the “Default.sprj” file with notepad, search for “UseSecurityDescriptors” and set the value to “NO” and save the file.

Roaming, Local, LocalLow

Windows Vista and Windows 7 comes with three new folders namely “Local”, “LocalLow” and “Roaming” which has been created by Microsoft intentionally for the following reasons

• Better performance during logon

• Segregation of application’s data based on the usage level

Roaming

The folder “Roaming” by design ensures that ONLY absolutely essential data like “Favorites” “Desktop” and “Documents” travel with the user thereby making it as a roaming profile. Data stored inside this folder would be user’s preference for a particular application. For instance, Adobe products stores user’s settings in this folder. It is worth to remember that “Roaming” folder is synchronized with the server meaning bigger the size of roaming folder longer the time required to logon to a PC.

Local

The folder “Local” is designed to store any machine specific information which wouldn’t be synchronized with the server at logon time. Usually, this data is machine specific. This folder is equivalent to C:\Documents and Settings\Local Settings\Application Data on Windows XP.

LocalLow

This folder stores what Microsoft calls as “Low Integrity” data. IE8, for example, can only write to the locallow folder (when protected mode is on).

Where OSD Script Runs

Where the script runs

The script can run in the following two locations:

• Inside the Virtual Environment
• Outside the Virtual Environment

Set the PROTECT attribute as follows:

• PROTECT=True
  This setting configures the script to run in the Virtual Environment. You can use this setting to run scripts that are used to troubleshoot issues.
• PROTECT=False
  This attribute configures the script to run outside the Virtual Environment. For example, you can use this setting to run scripts that copy files locally to the client.

When OSD Script Runs

When the script runs

You can use the .osd file to run scripts at various times during the startup of App-V (SoftGrid)-enabled programs. The "SCRIPT TIMING and EVENT" setting in the script comes first. Under this setting, the following attributes determine when the script runs:

• PRE STREAM
  This attribute runs the script before the program starts streaming. For example, use this attribute when you have to open a virtual private network (VPN) connection to the App-V (SoftGrid) server before you run the program.
• POST STREAM
  This attribute runs the script after authorization and after the program starts streaming but before the Virtual Environment is set up.
• PRE LAUNCH
  This attribute runs the script inside the virtual environment before the program runs.
• POST LAUNCH
  This attribute runs the script after the program is started.
• POST SHUTDOWN
  This attribute runs the script after the program is shut down. For example, use this attribute to clean up configuration settings or to delete configuration files.

How OSD script runs

How the script runs

The new TIMEOUT attribute determines the following:

• Whether the App-V (SoftGrid) client waits for the script to finish
• The period that the App-V (SoftGrid) client will wait for the script to finish

For backward compatibility, the WAIT attribute is still supported in Microsoft App-V 4.x and in Microsoft SoftGrid 4.x. 

Set these attributes as follows:

TIMEOUT
• TIMEOUT=x
  The client will wait x seconds for the script to finish before the client returns an error.
• TIMEOUT=0
  The client will wait indefinitely for the script to finish.

WAIT
• Wait=False
  The client will continue without waiting for the script to finish.
• Wait=True
  The client will not start the next step until the script finishes.

Notes

• The client does not support a pre-shutdown event. You cannot determine the exact moment at which a user will perform a shutdown. For example, you cannot predict when the user will clickClose or when the user will press ALT+F4.
• You can use scripts in any language. However, the language must be installed locally on the client computer.

AppV OSD Script - Map Network Drive

This sample script does the following:

It uses the SCRIPTBODY tag to contact a server by using its IP Address.
It deletes a drive mapping, and then it creates a new drive mapping by using the same drive letter.

<DEPENDENCY>
<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE">
<SCRIPTBODY> @echo on \n
ping 192.168.100.100 \n
net use x: /delete /y \n
net use x: \\\\ServerName\\Achieve \n
net use y: /delete /y \n
net use y: \\\\ServerName\\Achieve\\claims\\Bethany \n
</SCRIPTBODY>
</SCRIPT>
</DEPENDENCY> 

AppV OSD Script Example

This script does the following:

It uses the SCRIPTBODY tag to map a network drive to a server's netlogon share.
It calls an existing .cmd file that is located on the mapped network drive.
It calls the Editini.exe file.
It adds a Temp path to the Word.ini file.

DEPENDENCY>
<SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="TRUE" WAIT="TRUE">
<SCRIPTBODY>
net use k: \\\\w2k-pdc\\netlogon \n
CALL k:\\usr-w2k.cmd \n
\\\\sft-softgrid\\shr\\editini.exe c:\\word\\word.ini "FileLocations" TempPath c:\\tem \n
</SCRIPTBODY>
</SCRIPT>
</DEPENDENCY>

App-V 5.0 Beta: No more OSDs?

The publishing process no longer points to App-V client launcher program (sfttray.exe).  


Now in AppV 5.0, The shortcut points to actual exe, hence OSDs are not required.

App-V Client Offline Mode Settings

Following registries needs to be changed on App-V Client systems to run AppV client in Standalone/Offline modde

On 32bit machines the registry path is HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client


On 64bit machines the registry parth is
HKLM\SOFTWARE\Wow3264Node\Microsoft\SoftGrid\4.5\Client


The settings required are:


HKLM\...\Configuration AllowIndependentFileStreaming 1
HKLM\...\Configuration RequireAuthorizationIfCached 0
HKLM\...\Network AllowDisconnectedOperation         1
HKLM\...\Network LimitedDisconnectedOperation 0

Custom Action Conditions in MSI

You can execute a custom action or make the component install using conditions as per the requirement.

1. Condition for Action to run only during Installation
   Condition: NOT Installed
2. Condition for Action to run only during Uninstallation/Removal of MSI
   Condition: REMOVE="ALL"
3. Condition for Action to run during Install and repair
   Condition: NOT REMOVE
4. Condition for Action to run only during Upgrade

       Condition: NOT UPGRADINGPRODUCTCODE

Append Entries to Hosts file

Following script can be used to append entries in HOSTS file.

A text file containing the entry to be appended should be placed in INPUT location as in below script

Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim TargetFile,objWshShell,objFSO, Input, ProgramFiles, WinDir
Dim objTextFile, Target

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

ProgramFiles = ObjWshShell.ExpandEnvironmentStrings("%ProgramFiles%")
WinDir = ObjWshShell.ExpandEnvironmentStrings("%WinDir%")

Set Targetfile = objFSO.GetFile(WinDir & "\system32\drivers\etc\hosts")
Set Input = objFSO.GetFile(ProgramFiles & "\Input.txt")

Set objTextFile = objFSO.OpenTextFile (Input, ForReading)
Set Target = CreateObject("Scripting.FileSystemObject")
Set TargetFile = Target.OpenTextFile (TargetFile, ForAppending, True)

Do Until objTextFile.AtEndOfStream
Input = objTextFile.ReadLine
TargetFile.WriteLine(Input)
Loop

TargetFile.Close
ObjTextFile.Close
objFSO.DeleteFile(ProgramFiles & "\Input.txt")

VBScript to find MAC Address of a machine

VBScript to find the MAC Address of Network Adaptors attached to a computer.

On Error Resume Next
Dim strComputer
Dim objWMIService
Dim colItems

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _ 
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_NetworkAdapterConfiguration")

For Each objItem in colItems
    Wscript.Echo "MAC Address: " & objItem.MACAddress
Next

Set Permissions using SetACL

Using SetACL to provide permissions

Command1: Providing registry permissions to Authenticated Users group

setacl.exe "MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /grant "Authenticated Users" /full /i:cont_obj_inh /p:yes /r:cont_obj /silent

OR using S-ID

"MACHINE\SOFTWARE\AHouse\GEPUIS ORBIX" /registry /set "S-1-5-11" /full /sid /silent

Command2: Providing Folder permissions to Authenticated Users group

setacl.exe "c:\AudioTools\GIMP" /dir /set "S-1-5-11" /change /sid /silent

Change the group name / S-ID according to your requirement

Resolve ICE38 Error

ERROR: Component DesktopFolder installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.

Solution: In the Components Tab, find the CurrentUser component, which holds all the user's information. Pick one of the registry keys (except the one set as a keypath), right click on it and select the option 'Move'. Move that key to the component referred on the ICE error message. Go to that component, open it and find the 'new key'. Right click on the entry and select 'Set as Key' option.

Create Minor Upgrade MSI

Steps to create Minor Upgrade:

1. Change the Package code and Product Version to create a minor upgrade
2. Add feature / component by following the guide lines in Section: Requirement for Minor upgrade
3. Add Remove or Modify files, registry keys and shortcuts.
4. Add minor upgrade item in upgrades view (this is optional).
5. Build and use the installer for upgrade.

Resolve ICE18 Error

Error: KeyPath for Component “…” is Directory “…”. The Directory is not listed in the CreateFolders table

Solution: Create a new row in the table “CreateFolder”, select the mentioned Directory and the mentioned Component.

Resolve ICE43 Error

Error: Component “…” has non-advertised shortcuts. It Should use a registry key under HKCU as its KeyPath, not a file.

Solution: Put one Current_User registry key under the mentioned component and set that registry key as the keypath

Resolve ICE57 Errors

Error: Component has both per user and per machine data with a per machine keypath

Solution: Create a new component (with a new GUID), move all of the per user data from the component that kicks up the error to the new one. Set one of the files/reg keys as it’s keypath.

Stop & Delete Service - VBScript

Option Explicit


On Error Resume Next


Dim objWshShell


Set objWshShell = CreateObject("WScript.Shell")


objWshShell.Run "sc stop ServiceName",0,true
objWshShell.Run "sc delete  ServiceName ",0,true


Set objWshShell = Nothing

Delete Files of common name - VBScript

Suppose cr123.tmp, crequ.tmp, crkkin.tmp...........etc files are present under C:\Windows folder


The following script can be used to delete cr*.tmp files from C:\Windows folder


strDir = "C:\WINDOWS"
Set fso = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")
Set objDir = FSO.GetFolder(strDir)
getInfo(objDir)
Sub getInfo(pCurrentDir)


For Each aItem In pCurrentDir.Files
If (LCase(Left(Cstr(aItem.Name), 2)) = "cr") AND fso.GetExtensionName(LCase(aItem.Name)) = "tmp" Then
aItem.delete(True)
End If
Next
For Each aItem In pCurrentDir.SubFolders
'wscript.Echo aItem.Name & " passing recursively"
getInfo(aItem)
Next
End Sub

Check Admin Rights

Check if the current user is a local administrator using the Windows Installer service.


Dim oInst, oSess, iAdmin, oProducts
Const msiUILEVELNONE = 2
Set oInst = CreateObject("WindowsInstaller.Installer")
oInst.UILevel = msiUILEVELNONE
Set oProducts = oInst.Products
Set oSess = oInst.OpenProduct(oProducts(0))
iAdmin = oSess.Property("AdminUser")
If iAdmin = 1 Then
Msgbox "You are a local administrator!", vbInformation, "ADMINISTRATOR"
Else
Msgbox "You are not a local administrator!", vbCritical, "NON-ADMIN"
End If

ChangeBASE AOK Plug-in for VMware ThinApp

ChangeBASE AOK, the world leader in automated application compatibility testing and remediation, today announces the first VMware ThinApp Plug-in to aid enterprise application compatibility in a virtualized environment.


For more information, please visit VMBlog

Changebase AOK Features

• Compatibility Assessment - Identify compatibility issues before deploying an application to the target environment for accurate and informed decisions on timeframes and costs. Automatically assess application suitability for target environments to prioritize applications for relicensing, replacement and testing. Include nonstandard or legacy applications to test your entire inventory of applications for compatibility issues.
• Microsoft Office Dependency Testing - Highlight potential issues for applications that will be integrated with Office 2007/2010. Identify dependencies on versions of Microsoft Office prior to 2007/2010 that may create issues and cause those applications to fail. Ensure application packages are compliant with Active Directory policies.
• Auto-Fix Compatibility Issues - Resolve application compatibility issues pre-deployment with minimal manual effort, to avoid repeated assessment cycles and to substantially accelerate application delivery. Reduce post-migration support issues for a faster, less-costly and more thorough migration process than what is possible with competing solutions.
• Ongoing Management - Take advantage of the latest Windows updates and patches through periodic automated re-evaluation of your application estate. Reduce security risks and speed deployment times by completing patch impact assessments within minutes. Introduce changes quickly, easily and reliably—with the highest degree of confidence.
• Virtual Compatibility Assessment - Determine which applications you can virtualize within seconds and track for middleware dependencies, saving days of testing time.
• Auto-Fix for Virtual Platforms - Evaluate applications for compatibility issues with target virtual platforms and repair them in just a few simple steps.
• Automation of Corporate Packaging Standards - Test for issues related to in-house and packaging (MSI) standards and apply automated fixes to easily ensure compliance. Develop and customize QA checks and related remedies to achieve significant time and cost savings compared to manual checking.
• Application Virtualization - Automatically virtualize your applications. Save time, avoid errors and meet demand faster versus manual conversions.
• Browser Compatibility and Testing - Identify web site and web application compatibility issues with Internet Explorer 8/9 and Firefox.
• Application Readiness Dashboards - Leverage online dashboards that present graphs, charts, calculators, project status and next-step wizards,

Difference Between Refresh DP and Update DP

Update distribution points increments the package version, goes to the source location, constructs new package content but only sends the delta between what is already present on the DP and what is currently in the new package source. Also this action is package specific and once you trigger this action all the DPs to which the package has been distributed will get the new version.

Refresh distribution points does not increment the package version but simply sends out the current version of the package content again to a specific DP. So this is action is specific to a package-DP assocation and should be used when the content on any particular DP appears corrupted.

SCCM Client Logs

Following are the SCCM Client logs and their usage


CAS.log: Provides information about the process of downloading software updates to the local cache and cache management.

CIAgent.log:Provides information about processing configuration items, including software updates.

LocationServices.log: Provides information about the location of the WSUS server when a scan is initiated on the client.

PatchDownloader.log:Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.

PolicyAgent.log: Provides information about the process for downloading, compiling, and deleting policies on client computers.

PolicyEvaluator:Provides information about the process for evaluating policies on client computers, including policies from software updates.

RebootCoordinator.log:Provides information about the process for coordinating system restarts on client computers after software update installations.

ScanAgent.log: Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.

ScanWrapper.log:Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.

SCCM Client Installation Issues

Check following points

1.       The login ID should have Admin Access.

2.       following services should automatic and running

• a.      BITS
• b.      Automatic updates
• c.      Distribution transaction coordinator

3.       Windows Firewall should be stopped and disabled.

4.       minimum 250mb free space in system drive

5.       Latest service pack have to  be installed

VMWare Workstation 8

Latest release of VMWare Workstation 8 can be downloaded using following URL


http://www.vmware.com/products/workstation/overview.html


VMWare Server is discontinued

MsiLockPermissionsEx Table

MsiLockPermissionsEx Table enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer

·Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o Ability to apply Deny ACLs to objects

o Indicate inheritance properties for permissions

o Expand the set of well-known SIDs

o Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

·Security settings can be applied to services as well in addition to Files, Folders, Registry keys

·Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation
Read more about this in Windows installer team blog

http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx

1E Nomad Branch

Users in the remote branches will be benified from Nomad in Software Distribution. Nomad has a very tight integration with Microsoft SMS and SCCM Config Manager .


Once the data is distributed by Nomad Branch , it shares the data with Peer's. You can configure Nomad branch with or without multicasting.


Benefits of Nomad Branch


- Cost Reduction by reducing the number of Servers in Branches
- Bandwidth Control
- Multicasting

Shared DLLS vs Merge Modules

Merge modules are similar in structure to a simplified Windows Installer, which helps to integrate shared code, files (DLLs / OCXs), resources, registry entries, and setup logic to applications as a single compound file.

Drawback of using downloadable Merge Modules while re-packaging: Most of the merge modules are present in their respective shared location, if not; it’s downloaded from the web. As the files integrated with the installer is from merge modules, it does not require isolation.
When you don’t find the proper network for the Share location on web during installation, then the application / installation fails to function. This is the main drawback of the Merge Modules. Shared DLL concept can be used to overcome this issue.
During the re-packaging process usually we don’t include the merge modules, that has to be downloaded during installation, in the WSI/MSI; this is to avoid the above mentioned network issues. The following screen shot shows how the merge modules will be excluded in the package:

In this case the DLL/ OCX files will be included directly within the WSI/ MSI.

Shared DLLs:
All the DLLs captured in the WSI/ MSI will be a shared DLL. When a DLL is already present in the machine and if we install the application, the DLL of the same version increments its DLL counter. Since the DLLs from the MSI are shared DLLs, any new application that would be installed on the same machine in future will increment the corresponding DLL count. All the Shared DLL counts can be viewed from the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls When there is a DLL conflict found using Wise Conflict Manager, we go for Isolation. This is named as DLL Redirection.

What is DLL Redirection?Since an executable imports API functions from DLL files, DLL redirection allows us to tell a program that the DLLs it needs are located in a different directory than the originals; in this way we can create a DLL with the same name as the original, which exports the same function names as the original, but each function can contain the code of developer’s choice.

There are two ways to achieve DLL redirection;

1. “dot local” redirection:
   “Applications can depend on a specific version of a shared DLL and start to fail if another application is installed with a newer or older version of the same DLL. There are two ways to ensure that your application uses the correct DLL: DLL redirection and side-by-side components. Developers and administrators should use DLL redirection for existing applications, because it does not require any changes to the application. “
   In other words, dot local DLL redirection affords developers the ability to force an application to use a different version of a particular DLL file than that used by the rest of the system. For example, if an application called oldapp.exe only worked with an outdated version of user32.dll, then instead of replacing the user32.dll file in the system32 directory (potentially causing many other applications to break), you could tell it to load the older version of user32.dll from the program's current directory by creating an appropriate dot local file. All other applications will still load the newer DLL from system32 and remain unaffected. All that is needed is to create a dot local file (which is simply an empty file whose name contains the name of the target application followed by a .local extension; in this case it would be oldapp.exe.local), and place it and the older version of user32.dll in the same directory as oldapp.exe.
   Limitations with “dot local” redirection:
   Most notably, according to MSDN, certain DLL files (called 'Known DLLs') cannot be redirected in Windows XP (this restriction does not apply to Windows 2000). A list of all Known DLLs can be found in the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs key; included in the list of known DLLs are kernel32.dll, user32.dll and gdi32.dll. However, this is not true - it seems that under Windows XP, an application will either allow you to redirect any DLL, or none at all. As such, if targeting a program running on the Windows XP platform, dot local redirection is an unreliable method, and should be used only on Windows 2000 machines.
2. Using Manifest Files:Manifest files use the same naming convention as dot local files (i.e., oldapp.exe.manifest), but are not empty files. They must contain certain XML-formatted information in order to function properly, or else the target application will fail to load. In addition, manifest files are only supported on Windows XP and Vista; however, they are far more reliable than using dot local redirection, and allow us to redirect any DLL file. (NOTE: The testing was done under Windows XP only; it is possible that some restrictions/changes may be applied to Windows Vista).

What is a shared file?

A shared file is a file that can be used by more than one application. The Windows operating system provides a number of shared files that can be used by any application installed. Software developers can also create shared files for their own applications. Shared files allow for the creation of more efficient applications and save time because the same code does not have to be created for each application. It is created once and used by many applications.

During installation, files identified as shared are registered in the Windows registry. Each time the shared file is installed, the registry increments the registry value associated with it. This registry value is also known as the ref count or the shared reference count. So if two applications install the same shared file, the registry value (ref count) is 2. During uninstallation, a shared file's registry value is decremented. When the registry value reaches 0 the file will be deleted

What is Windows Installer

The Windows Installer engine (also called the MSI engine) drives the installation of your application. It is a part of the Windows Installer Service, a technology developed by Microsoft to standardize installations on the Windows platform. Without the Windows Installer engine, installations using the Windows Installer technology cannot be installed. The Windows Installer engine is already installed on Windows XP. For other operating systems, the Windows Installer engine must be installed by the installation or by the home user. Most installations based on the Windows Installer Service automatically install the Windows Installer engine on the computer prior to running the installation. In case of an error or other unexpected behavior, you may need to install the engine manually.

What is Registry

The registry is a central database used by the Windows operating system to track your personal settings and the software and hardware installed on your computer. When you install an application, installation choices are written to the registry. The registry contains 5 major branches:

• HKEY_CLASSES_ROOT – contains information on file-related behavior including what files are associated with what applications
• HKEY_CURRENT_USER – contains the preferences of the current user
• HKEY_USERS – contains the preferences of each user on the system
• HKEY_LOCAL_MACHINE – contains operating system, hardware, and application settings
• HKEY_CURRENT_CONFIG – contains hardware settings users can modify for different circumstances

Disadvantages of Nested MSI Installation

The disadvantages of using the Nested MSI's are,

• Nested Installations cannot share components.
• An administrative installation cannot contain a nested installation.
• Patching and upgrading will not work with nested installations.
• The installer will not correctly cost a nested installation.
• Integrated ProgressBars cannot be used with nested installations.
• Resources that are to be advertised cannot be installed by the nested installation.
• A package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.

Disadvantages of SelfReg Table Entries

• Rollback of an installation with self-registered modules cannot be safely done using DllUnregisterServer because there is no way of telling if the self-registered keys are used by another feature or application.
• The ability to use advertisement is reduced if Class or extension server registration is performed within self-registration routines.
• The installer automatically handles HKCR keys in the registry tables for both per-user or per-machine installations. DllRegisterServer routines currently do not support the notion of a per-user HKCR key.
• If multiple users are using a self-registered application on the same computer, each user must install the application the first time they run it. Otherwise the installer cannot easily determine that the proper HKCU registry keys exist.
• The DllRegisterServer can be denied access to network resources such as type libraries if a component is both specified as run-from-source and is listed in the SelfReg table. This can cause the installation of the component to fail to during an administrative installation.
• Self-registering DLLs are more susceptible to coding errors because the new code required for DllRegisterServer is commonly different for each DLL. Instead use the registry tables in the database to take advantage of existing code provided by the installer.
• Self-registering DLLs can sometimes link to auxiliary DLLs that are not present or are the wrong version. In contrast, the installer can register the DLLs using the registry tables with no dependency on the current state of the system.

VBScript to Display Countdown Timer

Following script displays countdown timer



Dim counter
Dim oShell
counter = 10
Set oShell= CreateObject("Wscript.Shell")
While counter > 0


oShell.Popup " Left " & counter & " Seconds",1,"Remind"
counter = counter-1
Wend

What is application packaging

Set Shortcut Working Directory - VBScript

Following script checks for Windows XP or Windows7 and sets working directory accodingly.


'Option Explicit


Dim objShell, ALLUSERSPROFILE, SysDrive, objShtCut


Set objShell = WScript.CreateObject("WScript.Shell")
ALLUSERSPROFILE =objShell.ExpandEnvironmentStrings("%ALLUSERSPROFILE%")
APPDATA =objShell.ExpandEnvironmentStrings("%APPDATA%")




strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")


Set colOperatingSystems = objWMIService.ExecQuery _
    ("Select * from Win32_OperatingSystem")


For Each objOperatingSystem in colOperatingSystems
    ver= objOperatingSystem.Caption 
Next


S = InStr(ver,"XP")




If S > 0 Then


Set objShtCut = objShell.Createshortcut(ALLUSERSPROFILE &"\Start Menu\Programs\SampleTest.lnk")
objShtCut.WorkingDirectory = APPDATA & "\Sample"

objShtCut.Save


else


Set objShtCut = objShell.Createshortcut(ALLUSERSPROFILE &"\Microsoft\Windows\Start Menu\Programs\SampleTest.lnk")
objShtCut.WorkingDirectory = APPDATA & "\Sample"
objShtCut.Save


end if
WScript.Quit