Wednesday, 26 October 2011

Reader 9.4.6 Deployment Error: 1646



Error 1646

During Adobe Reader patch deployment in the client domain of around 6000+ machines, application was unable to upgrade to latest version and failing with the Error – 1646 as per the SCCM reports for around 200 machines. In report Error – 1646 won’t provide the detailed information why the application failed or reference to source of error.
Reason for the Error:
Even though deployment was successful since considering the percentage of success there is a need to fix the issues so that in future we should not face the similar kind of issues.
During earlier version deployment of Adobe reader application was leaving behind the entries of old versions (registry entries as below) as a reason it will display in ADD-Remove Programs of 2 versions entries.
FIG -1
clip_image004
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ Products\68AB67CA7DA73301B7449A0400000010\Patches\68AB67CA7DA700005205A7C804009054
Uninstallable=0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\68AB67CA7DA73301B7449A0400000010\Patches\68AB67CA7DA700005205A7C804009034 "
Uninstallable=0

Possibility of such a errors could be during installation of application if user is using reader application then it would locked the registries of older version and would have been not removed.
Solution:
While upgrading to latest version of adobe reader (9.4.6) it was failing to upgrade as registries are (as above) string value Uninstallable=0 of old version entries (i.e. 9.4.5and 9.4.3) which won’t allow for un-installation of the application.By enabling the registry value to Uninstallable=1 enable to uninstall of older version and upgrade to latest versions,
To address this change wrote a script to change the registries and run the advertisement on failed machines which gave successful results.
Adobe Reader 9.4.6 registry modification script
'==========================================================
' ' COMMENT:
' Script will check value name of the string “Uninstallable” oIf value is equal to ZERO(Uninstallable=0)
' then script should modify it to 1
'
'
'
'==========================================================
public Const HKEY_LOCAL_MACHINE = &H80000002
strKeyPath = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\68AB67CA7DA73301B7449A0400000010\Patches\68AB67CA7DA700005205A7C804009034\Uninstallable"
x=readreg (strkeypath)
‘msgbox "Value 1# "&x
'******* if regkey value is 0 then key will set to 1 **********************************
if x=0 then
strKeyPath1 = "SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\68AB67CA7DA73301B7449A0400000010\Patches\68AB67CA7DA700005205A7C804009034"
regkey="Uninstallable"
strvalue ="1"
addreg strkeyPath1, regkey, strvalue, 4
end if
x=readreg (strkeypath)
‘msgbox "2 "&x
if x=1 then
x=0
else
x=6
end if
‘msgbox x
wscript.quit(x)
'********************* Adding registry key ******************************
function addreg(strKeyPath, regkey, strValue, regtype )
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\default:StdRegProv")
‘msgbox "strkeypath "&strkeypath
‘msgbox regkey
oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strkeypath,regkey, strValue
end function
'***************** Read registry key ********************
function readreg (strRegistryKey )
Dim WSHShell, value
On Error Resume Next
Set WSHShell = CreateObject("WScript.Shell")
‘msgbox " strRegistryKey " &strRegistryKey
value = WSHShell.RegRead( strRegistryKey )
‘msgbox "value " &value
if err.number <> 0 then
readreg= "6"
else
readreg=value
end if
set WSHShell = nothing
end function





















































































Thursday, 13 October 2011

SCCM Log Files

1 Which are logs on client machine, which are frequently used.
Execmgr.log Records advertisements that run.
CcmExec.log Records activities of the client and the SMS Agent Host service.
LocationServices.log Finds management points and distribution points.

Client Log Files

The Configuration Manager 2007 client logs are located in one of the following locations:
  • On computers that serve as management points, the client logs are located in the %ProgramFiles%\SMS_CCM\Logs folder.
  • On all other computers, the client log files are located in the %Windir%\System32\CCM\Logs folder or the %Windir%\SysWOW64\CCM\Logs.
The following table lists and describes the client log files.
Log File Name Description
CAS.log Content Access service. Maintains the local package cache.
CcmExec.log Records activities of the client and the SMS Agent Host service.
CertificateMaintenance.log Maintains certificates for Active Directory directory service and management points.
ClientIDManagerStartup.log Creates and maintains the client GUID.
ClientLocation.log Site assignment tasks.
ContentTransferManager.log Schedules the Background Intelligent Transfer Service (BITS) or the Server Message Block (SMB) to download or to access SMS packages.
DataTransferService.log Records all BITS communication for policy or package access.
Execmgr.log Records advertisements that run.
FileBITS.log Records all SMB package access tasks.
Fsinvprovider.log (renamed to FileSystemFile.log in all SMS 2003 Service Packs) Windows Management Instrumentation (WMI) provider for software inventory and file collection.
InventoryAgent.log Creates discovery data records (DDRs) and hardware and software inventory records.
LocationServices.log Finds management points and distribution points.
Mifprovider.log The WMI provider for .MIF files.
Mtrmgr.log Monitors all software metering processes.
PolicyAgent.log Requests policies by using the Data Transfer service.
PolicyAgentProvider.log Records policy changes.
PolicyEvaluator.log Records new policy settings.
RemoteControl.log Logs when the remote control component (WUSER32) starts.
Scheduler.log Records schedule tasks for all client operations.
Smscliui.log Records usage of the Systems Management tool in Control Panel.
StatusAgent.log Logs status messages that are created by the client components.
SWMTRReportGen.log Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.)
Site Server Log Files
Most Configuration Manager 2007 site server log files are located in the <InstallationPath>\LOGS folder. Because Configuration Manager 2007 relies heavily on Internet Information Services (IIS), you can review the IIS log file for additional errors that relate to client access to the IIS server. The IIS log file is located in the %Windir%\System32\Logfiles\W3SVC1 folder on the IIS server.
The following table lists and describes the site server log files.

Log File Name Description
Adsgdis.log Records Active Directory Security Group Discovery actions.
Adsysgrp.log Records Active Directory System Group Discovery actions.
Adsysdis.log Records Active Directory System Discovery actions.
Adusrdis.log Records Active Directory User Discovery actions.
Ccm.log Client Configuration Manager tasks.
Cidm.log Records changes to the client settings by the Client Install Data Manager (CIDM).
Colleval.log Logs when collections are created, changed, and deleted by the Collection Evaluator.
Compsumm.log Records Component Status Summarizer tasks.
Cscnfsvc.log Records Courier Sender confirmation service tasks.
Dataldr.log Processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager 2007 database.
Ddm.log Saves DDR information to the Configuration Manager 2007 database by the Discovery Data Manager.
Despool.log Records incoming site-to-site communication transfers.
Distmgr.log Records package creation, compression, delta replication, and information updates.
Hman.log Records site configuration changes, and publishes site information in Active Directory Domain Services.
Fspmgr.log Records activities of the fallback status point site system role.
Inboxast.log Records files that are moved from the management point to the corresponding SMS\INBOXES folder.
Inboxmgr.log Records file maintenance.
Invproc.log Records the processing of delta MIF files for the Dataloader component from client inventory files.
Mpcontrol.log Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes.
Mpfdm.log Management point component that moves client files to the corresponding SMS\INBOXES folder.
MPMSI.log Management point .msi installation log.
MPSetup.log Records the management point installation wrapper process.
Netdisc.log Records Network Discovery actions.
Ntsvrdis.log Records NT Server Discovery.
Offermgr.log Records advertisement updates.
Offersum.log Records summarization of advertisement status messages.
Policypv.log Records updates to the client policies to reflect changes to client settings or advertisements.
Replmgr.log Records the replication of files between the site server components and the Scheduler component.
Rsetup.log Reporting point setup log.
Sched.log Records site-to-site job and package replication.
Sender.log Records files that are sent to other child and parent sites.
Sinvproc.log Records client software inventory data processing to the site database in Microsoft SQL Server.
Sitecomp.log Records maintenance of the installed site components.
Sitectrl.log Records site setting changes to the Sitectrl.ct0 file.
Sitestat.log Records the monitoring process of all site systems.
Smsdbmon.log Records database changes.
Smsexec.log Records processing of all site server component threads.
Smsprov.log Records WMI provider access to the site database.
Smsfspsetup.log Records messages generated by the installation of a fallback status point.
SMSReportingInstall.log Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes.
Srvacct.log Records the maintenance of accounts when the site uses standard security.
Statmgr.log Writes all status messages to the database.
Swmproc.log Processes metering files and maintains settings.

The Admin UI log files are located in <InstallationPath>\AdminUI\. The following table lists and describes the Admin UI log files.
Log File Name Description
RepairWizard.log Records errors, warnings, and information about the process of running the Repair Wizard.
ResourceExplorer.log Records errors, warnings, and information about running the Resource Explorer.
SMSAdminUI.log Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites.




SMS 2003 – Basic Software Distribution Troubleshooting Tips

Is the client getting the advertisement policy?
1.      Check the ccmexec.log for the advertisementID.
2.      If the advertisementID is not in the ccmexec.log, check the ccmexec.log for errors communicating with the Management Point.
3.      If the ccmexec.log shows errors communicating with the MP, follow basic connectivity tests such as pinging the MP by IP address, pinging the MP by hostname and telnetting to port 80 on the MP. 
4.      If the ccmexec.log indicates the client can communicate with the MP, check the Management Point to see if the policy exists using SMS Client Centre tool.
5.      If the policy is not on the MP, ensure communications from the site server to the Management Point.
Is the client able to Locate a Distribution Point?
1.      Evaluate the LocationServices.log to determine which management points we are using.
2.      Evaluate the CCMExec.log and policy logs to make sure the client is connecting successfully to the management point.
3.      Evaluate the CAS.log to determine if the content location is being returned correctly.
4.      Ensure roaming boundaries are configured correctly and do not overlap with boundaries from the home site of the client.
5.      Ensure the distribution point servers are online.
6.      Ensure the command line for the package is correct.
Is the client able to access content on the Distribution Point?
1.     Verify the computer account has access to the share by checking the NTFS permissions on the SMSPKG<driveletter>$ share as well as the individual package folders inside. These permissions may be set explicitly or through group membership.
2.      If configured, verify the network access account has appropriate permissions, either through explicitly adding the account or membership in appropriate groups that already are granted rights.
3.      Verify appropriate credentials by logging on as either the network access account or computer account and attempting to access the distribution point share.















How To Read A Windows Installer Verbose Log

 
This document explains the main concepts of how to read a verbose log file created by the Windows Installer.  Non-verbose logs may not contain as much information talked about below and may not provide enough useful information for a failed setup installation.
Verbose logs will contain at least the following information:
  • Errors that occur during the installation including internal Windows Installer errors
  • All standard actions executed as well as any custom actions that were executed
  • If a reboot was requested and completed
  • The source location of the installation media
  • If the installation was completed
  • If the installation was rolled back, this will also be notated in the log
On Windows NT 4, Windows 2000 and Windows XP, the Windows Installer executes an installation in two distinct processes.  One is a client process and the other is a server process.  The log file will show the installation information for both processes.  An installation on a Windows 98, Windows 98 or Windows Millennium will run only in a client process, there is no concept of a server process on these platforms.  In a typical verbose log file, you will see lines like the following for a line that denotes the information presented was done on the client context of the installation:
MSI (c) (29:28) : Resetting cached policy values
In a typical verbose log file, you will see lines like the following for a line that denotes the information presented was done on the server process of the installation:
        MSI (s) (A0:EC): Original package ==> D:\TEMP\Default.msi
The (29:28) and (A0:EC) entries above represent the last two digits of the process and thread ids respectively that generated the entry in the log file.  Generally, this information is not too useful but can shed some light on which process and thread is associated with log entry.  In the above entry, we also see where the original source package is located at.  In this case, if an uninstall or repair is performed, the location of the package will be first read from d:\temp\default.msi.
The log file will first show the client process while the setup user interface is running.  After the setup user interface has been completed by the end user, the log file will show the a line like the following:
        MSI (c) (29:28) : Switching to server: COMPANYNAME="Microsoft" USERNAME="Admininstrator" ...
This line signals that the installation execution is now passing to the server process.  Only approved public properties which will be in all uppercase are propagated to the server process to enforce the final changes of the setup installation.  Non-uppercase properties are considered private properties and are not passed to the server process.
The beginning of the server process will look very similar to the beginning of the client process.  The service must re-evaluate all of the settings to prevent a user without sufficient privileges from performing a setup request that should not allowed.  This includes revaluating the private properties, policies and other installation state settings such as the features and components to be installed.
The  server process performs the actual installation functions such as copying files, writing to the registry, etc.  Most actions appear in two forms in a verbose log file.  The first form is to add it to the installation script that will be ran later on in the installation.
    MSI (s) (24:24): Doing action: RegisterTypeLibraries
Action start 13:02:32: RegisterTypeLibraries.
    GenerateScript: Registering type libraries
Action ended 13:02:32: RegisterTypeLibraries. Return value 1.
The second form is the actual execution of the action:
        MSI (s) (24:24): Executing op: ActionStart(Name=RegisterTypeLibraries,Description=Registering type libraries,Template=LibID: )
        Action 13:04:42: RegisterTypeLibraries. Registering type libraries
For standard and custom actions, the return values can be one of the following values in the table.  For more information on the return values, please see the help file topic Logging of Action Return Values in the the Windows Installer SDK.
Value
Meaning
0
action not executed
1
success
2
user canceled
3
fatal error
4
suspended, waiting for a reboot
In the example above, we see that the return value for the RegisterTypeLibraries standard action was 1 meaning the action completed successfully.  If this action failed and caused an error, a return value of 3 would have been returned and would have caused the rest of the installation to stop and the rollback process would begin which would return the system back to the same state before the installation began.
When copying  files, the log file will explain why a particular file was or was not copied.  This can be useful when trying to determine why a particular file is or is not copied to the machine.  An example line in the log file may look like the following, note the areas highlighted in bold.
       MSI (s) (34:A1): Executing op:
FileCopy(SourceName=Global_Vba_VBStockProp_f0.7EBEDD3E_AA66_11D2_B980_006097C4DE24,DestName=msstkprp.dll,Attributes=0,FileSize=94208,Version=6.0.81.69,Language=1033,InstallMode=58982400)
       MSI (s) (34:A1): File: C:\WINNT\System32\msstkprp.dll; Won't Overwrite; Existing file is of an equal version
Another useful item that is included in a verbose log file is the feature and component state values that are used during the installation.  The following  is an example entry in a verbose log file for a feature state, note the areas highlighted in bold.
       MSI (s) (34:A1): Feature: _MainFeature; Installed: Absent; Request: Local; Action: Local
For a feature state entry in the log file, the entry will be prefaced with Feature: and the feature name will follow.  In this case, the feature state being displayed is for the feature named _MainFeature. The Installed entry represents the current state of the feature on the machine.  When the setup package is being in installed for the first time, this value following Installed: will typically be Absent meaning the feature is not currently installed on the machine.  Other values are possible such as Local, Null, Request, etc.  For the complete list and their meaning, consult the MsiGetFeatureState documentation in the Windows Installer SDK.  The Request entry represents what the user has requested for the particular feature.  For this example, the user has requested to install the _MainFeature Local.  If this was an uninstall and the user selected to remove the _MainFeature feature, Request would be set to Absent which means to uninstall this feature.  A value of Null for Request would represent the feature will neither be installed nor removed.  The last entry, Action, represents what the Windows Installer is going to actually do for Request entry.  It would be rare that the Action entry did not equal the Request entry.  In this case, the Action to be taken is to install the _MainFeature locally to disk.
The following  is an example entry in a verbose log file for a component state, note the areas highlighted in bold.
        MSI (s) (34:A1): Component: Global_Notepad; Installed: Local; Request: Null; Action: Null
For a component state entry in the log file, the entry will be prefaced with Component: and the component name will follow.  In this case, the component state being displayed is for the component named Global_Notepad. The Installed entry represents the current state of the feature on the machine.  When the setup package is being in installed for the first time, this value following Installed will typically be Absent meaning the component is not currently installed on the machine.  For this example, Installed is set to Local meaning that the underlying component is already installed on the machine.  There are other values are possible for Installed such as Local, Null, Request, etc.  For the complete list and their meaning, consult the MsiGetComponentState documentation in the Windows Installer SDK.  The Request entry represents what the user has requested for the particular feature that this component belongs to.  For this example, the Windows Installer engine has determined based on the user's feature selection to do nothing for the Global_Notepad component which is denoted by Request being set to Null.  If this was an uninstall and the user selected to remove the feature that the Global_Notepad component belong to, Request could be set to Absent which means to uninstall this component.  The last entry, Action, represents what the Windows Installer is going to actually do for Request entry.  It would be rare that the Action entry did not equal the Request entry.  In this case, the Action to be taken is to neither install nor remove the Global_Notepad component.
If a setup installation encounters an error, a verbose log file will contain information about rolling back the installation.  You can find rollback information in the log file by searching for Rollback:.  The following line is an example line which states what action is currently being rolled back
        Rollback: Registering type libraries
In this example, we can see that the RegisterTypeLibraries standard action is rolling back the previous work done earlier in the installation when the RegisterTypeLibraries action executed.
At the end of the verbose log file is a complete property dump of the property names and values which can have either client and server properties listed, client only or server only depending on what operating system the log was generated on and what the user interface level was set to.  For example, in a quiet mode installation on Windows NT, 2000 or XP, only the server process is executed and only server process properties would be displayed at the end of the log file.  The following is an example line found in a verbose log file of a property and its value at the end of the client part of the installation before switching to the server process.
Property(C): USERNAME = someuser
This line shows the value of the USERNAME property on the client side of the installation before switching over to the server process was set to someuser.  You can tell this is a client property by noticing the C in the Property (C) notation.
The following is an example line found in a verbose log file of a property and its value at the end of the server part of the installation just before the installation terminated.
Property(S): USERNAME = someuser
This line shows the value of the USERNAME property on the server side of the installation was set to someuser.  You can tell this is a server property by noticing the S in the Property (S) notation.  Please note that the USERNAME property in this case has the same value on both the client and server side, however this may not always be the case for all properties as some properties may change on the server side due to custom actions changing the property.

























SCCM collection to list all the Laptop computers

If your boss ask to get list of laptops which are managed by SMS or SCCM.what do you do and how do you get that. Right click on computer and go to resource explorer to identify the computer is Laptop or Desktop ?
You can identify if the computer is Laptop or Desktop based on its chassis Types.
Below are listed the Chassis types available to create SCCM collection or reports.
For Laptops Chassis Types : 8 , 9, 10, 11, 12, 14, 18, 21
For Desktop Chassis Type : 3, 4, 5, 6, 7, 15, 16
For server Chassis  Type: 23
Below is the collection to list all the computers which are laptops which fall in above Chassis type.
You can also replace the values with Desktop computers or servers also you can use joins to club these with AD groups for deploying the applications based on this.
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ( "8", "9", "10", "11", "12", "14", "18", "21" )







How to troubleshoot the systems which has WMI issues ? (Rebuild WMI Repository)

Had several systems which had wmi issue in doing client /application installation.This is most common issue which we face if something happens to the system.To get solved,use the script which can be run remotely using psexec tool. http://blogs.technet.com/b/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx
Note : The below script tested only on Windows XP ,not tested on higher versions like Windows 7
Download the psexec tool from Microsoft .Here are the basic instruction in doing it.
1.copy the psexec.exe tool on to new folder (G:\script) and create 3 new files(wmifix.bat,computers.txt and run.bat).Each file script has given below.
wmifix:
@echo off
REM  WMI Repair
Title WMI Repair script running on the client machines
%windir%\system32\wbem\winmgmt /clearadap
%windir%\system32\wbem\winmgmt /kill
%windir%\system32\wbem\winmgmt /unregserver
%windir%\system32\wbem\winmgmt /regserver
%windir%\system32\wbem\winmgmt /resyncperf
net stop winmgmt /y
REM if exist %windir%\system32\wbem\repository.old rmdir /s /q %windir%\system32\wbem\repository.old
REM ren %windir%\system32\wbem\repository repository.old
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %%s in (‘dir /b /s %windir%\system32\wbem\*.dll’) do regsvr32 /s %%s
for /f %%s in (‘dir /b /s %windir%\system32\wbem\*.mof’) do mofcomp %%s
for /f %%s in (‘dir /b %windir%\system32\wbem\*.mfl’) do mofcomp %%s
net start winmgmt
%windir%\system32\wbem\wmiprvse /regserver






run.bat
@echo off
cd G:\script
G:
psexec @computers.txt -c G:\script\wmifix.bat
computers.txt
Add list of computers to the txt file which you have trouble.
Use the above script to fix wmi issues on computers,if that doesnt repair,remove the bold letters REM and try.this will delete the repository and recreates it for you to work wmi correctly.
more information about troubleshooting can be found from http://blogs.technet.com/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx









Failed to register IVIASPI drivers

1.What is iviaspi.dll doing on my computer?

iviaspi.dll is a iviaspi belonging to InterVideo ASPI Shell from InterVideo, Inc. Non-system processes like iviaspi.dll originate from software you installed on your system. As most applications store data in your system's registry, it is likely that your registry has suffered fragmentation and accumulated harmful errors. It is recommended that you
 
2.Why is iviaspi.dll giving me errors?

System process errors are mainly due to problems with conflicting applications running on your PC. Consider uninstalling any applications you are not using or use SpeedUpMyPC to selectively disable or remove unnecessary background and auto-start processes. The safest way to stop these errors is to uninstall the application

SMS 2003 – Basic Software Distribution Troubleshooting Tips

Is the client getting the advertisement policy?
1.      Check the ccmexec.log for the advertisementID.
2.      If the advertisementID is not in the ccmexec.log, check the ccmexec.log for errors communicating with the Management Point.
3.      If the ccmexec.log shows errors communicating with the MP, follow basic connectivity tests such as pinging the MP by IP address, pinging the MP by hostname and telnetting to port 80 on the MP. 
4.      If the ccmexec.log indicates the client can communicate with the MP, check the Management Point to see if the policy exists using SMS Client Centre tool.
5.      If the policy is not on the MP, ensure communications from the site server to the Management Point.
Is the client able to Locate a Distribution Point?
1.      Evaluate the LocationServices.log to determine which management points we are using.
2.      Evaluate the CCMExec.log and policy logs to make sure the client is connecting successfully to the management point.
3.      Evaluate the CAS.log to determine if the content location is being returned correctly.
4.      Ensure roaming boundaries are configured correctly and do not overlap with boundaries from the home site of the client.
5.      Ensure the distribution point servers are online.
6.      Ensure the command line for the package is correct.
Is the client able to access content on the Distribution Point?
1.     Verify the computer account has access to the share by checking the NTFS permissions on the SMSPKG<driveletter>$ share as well as the individual package folders inside. These permissions may be set explicitly or through group membership.
2.      If configured, verify the network access account has appropriate permissions, either through explicitly adding the account or membership in appropriate groups that already are granted rights.
3.      Verify appropriate credentials by logging on as either the network access account or computer account and attempting to access the distribution point share.