April 29 2011

Reasons to avoid Windows 7 32-bit

There is a great new post over here (http://adventuresinosd.blogspot.com/2011/04/top-10-reasons-to-avoid-windows-7-32.html) at Adventures in OSD on the reasons to avoid the 32-bit version of Windows 7 in the enterprise.

I strongly agree with all of his points and made one conclusion – if you are going to run a 32-bit OS then stick with Windows XP 32-bit, if you are going to run a 64-bit OS then run Windows 7 64-bit. Don’t give any other options.

I have deployed both 32 and 64 bit versions of Windows 7 in environments too and you are basically creating yourself twice the work with a nightmare of ongoing maintenance.

More here – http://adventuresinosd.blogspot.com/2011/04/top-10-reasons-to-avoid-windows-7-32.html



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

April 21 2011

SCCM packages “waiting to install package” installation status

I recently had a secondary site distribution point that wouldn’t recieve any packages, for every package there was “waiting to install package” installation status. The other 20-odd distribution points were fine.

I checked out the DISTMGR.LOG on the secondary site distribution point to find this, the last line was giving it away:

STATMSG: ID=2322 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=ALBDC01 SITE=S22 PID=4088 TID=8460 GMTDATE=Thu Apr 21 02:26:42.903 2011 ISTR0="P0000049" ISTR1="D:SMSPKGP0000049.PCK" ISTR2="d:_S M4hzx.TMP" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P0000049" SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
GetPackageSignature() called for package P0000049 with version 2. UnpackedSignature = 0 SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
d:SMSPKGSIGP0000049.2.tar could not be located SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
CreatePackageSignature() called for Package P0000049 with version 2 with source as d:_S M4hzx.TMP. KeepUnpackedSignature = 0 SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
failed to create instance of IRdcLibrary SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
CreateRdcSignature failed; 0x80040154 SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
CreateSignature failed SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
CreateRdcFileSignatureW failed; 0x80040154 SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)
RDC:Failed to generate signature from d:_S M4hzx.TMP for PkgID P0000049 and version 2, Error = 340 SMS_DISTRIBUTION_MANAGER 21/04/2011 12:26:42 PM 8460 (0x210C)

After reading this article (http://www.myitforum.com/forums/tm.aspx?high=&m=215540&mpage=1#215540), I found out that Remote Differential Compression wasn’t installed (this was a Windows 2003 server x86). So I found the msrdcoob_x86.exe file in the bin directory and tried to run it but got an error saying:

Setup could not verify the integrity of the file Update.inf. Make sure the Cryptographic service is running on this computer.

After Googling for a bit, I found the solution here – http://support.microsoft.com/kb/822798. I undertook the following 2 steps:

Method 2: Rename the Catroot2 folder
Rename the Catroot2 folder (Windows XP and Windows Server 2003 only), and then try to install the program again. Note Skip this method if the operating system is Windows 2000.
To rename the Catroot2 folder, follow these steps:
Click Start, click Run, type cmd, and then click OK.
At the command prompt, type the following commands, and then press ENTER after each line:
net stop cryptsvc
ren %systemroot%System32Catroot2 oldcatroot2
net start cryptsvc
exit
Remove all tmp*.cat files from the following folder:
%systemroot%system32CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}

If no files that start with tmp exist in this folder, do not remove any other files. The .cat files in this folder are necessary for installing hotfixes and service packs.
Important Do not rename the Catroot folder. The Catroot2 folder is automatically recreated by Windows, but the Catroot folder is not recreated if the Catroot folder is renamed.
Back to the top
Method 3: Reregister the DLL files that are associated with Cryptographic Services
To register .dll files that are associated with Cryptographic Services, follow these steps:
Click Start, click Run, type cmd in the Open box, and then OK.

Note On a Windows Vista-based computer, click Start, type cmd in the Start Search box, right-click cmd.exe, and then click Run as administrator.
At the command prompt, type the following commands, and press ENTER after each command:
regsvr32 /u softpub.dll
regsvr32 /u wintrust.dll
regsvr32 /u initpki.dll
regsvr32 /u dssenh.dll
regsvr32 /u rsaenh.dll
regsvr32 /u gpkcsp.dll
regsvr32 /u sccbase.dll
regsvr32 /u slbcsp.dll
regsvr32 /u mssip32.dll
regsvr32 /u cryptdlg.dll
exit
Note Click OK if you are prompted.

Note Microsoft Windows 2000 does not include the Sccbase.dll file. If you are running a version of Windows 2000, omit the Sccbase.dll file.
Restart your computer.
Click Start, click Run, type cmd in the Open box, and then click OK.
At the command prompt, type the following commands, and press ENTER after each command:
regsvr32 softpub.dll
regsvr32 wintrust.dll
regsvr32 initpki.dll
regsvr32 dssenh.dll
regsvr32 rsaenh.dll
regsvr32 gpkcsp.dll
regsvr32 sccbase.dll
regsvr32 slbcsp.dll
regsvr32 mssip32.dll
regsvr32 cryptdlg.dll
exit
Note Click OK if you are prompted.

Once that was complete, I went back and installed the msrdcoob_x86.exe file successfully. I then refreshed the distribution point for a test package that was causing problems, and within 5 minutes it had successfully been distributed to the secondary site distribution point.

I didn’t want to manually click refresh for the 139 packages that I needed to do, so I used a script I had to automate this. I have included these below.

1. Doall.bat: Entry point to the whole process that triggers the refresh of the DP’s for the packages. It calls redp.vbs for each package listed in PkgList.txt. Edit Doall.bat and modify the parameters of redp.vbs. The redp.vbs script has 3 parameters:
redp.vbs [TargetSiteCode] [PackageID] [DPname]
a) TargetSiteCode: Site code of the destination site. In my case, it is a secondary child site T03.
b) PackageID: The ID of the package of problem and will be retrieved from the PkgList.txt.
c) DPName: The script will only refresh the DP’s that contains a certain string in their names. In my case, since all the DP’s in T03 site have a name that contains the string “SMS_SITE=S22” in it, it will actually update all DP’s in T03. You can change it to a unique string, e.g., the DP server name, if you just need specific DP’s to be updated.

2. PkgList.txt: Contains a list of the package ID’s that we need to refresh. In my sample script there’re 2 packages: P000007B and P0000058.
3. Redp.vbs: For each package ID in the PkgList.txt, it queries the server WMI to find what DP’s have the package and triggers the refresh for each one.

Doall.bat

for /f %%i in (PkgList.txt) do call cscript redp.vbs T03 %%i SMS_SITE=S22

PkgList.txt

P000007B
P0000058

Redp.vbs

WScript.Echo "Refresh SMS DP"
if WScript.Arguments.Count<>3 then
WScript.Echo "Usage:"
WScript.Echo "redp.vbs [TargetSiteCode] [Packageid] [DPname]"
WScript.Quit
else
strPackageID = WScript.Arguments(1)
strSiteCode = WScript.Arguments(0)
strDpname = WScript.Arguments(2)
end if

WScript.Echo vbcrlf

'build site connection
Set objLoc = CreateObject("WbemScripting.SWbemLocator")
Set objSMS = objLoc.ConnectServer(strSMSServer, "rootsms")
Set Results = objSMS.ExecQuery ("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true")
For each Loc in Results
If Loc.ProviderForLocalSite = True Then
Set objSMS = objLoc.ConnectServer(Loc.Machine, "rootsmssite_" & Loc.SiteCode)
strSMSSiteCode = Loc.SiteCode
end if
Next
strQuery = "Select * From SMS_DistributionPoint WHERE " & "ServerNALPath is like '%" & strDpname & "%'" & " and SiteCode='" & strSiteCode & "' AND PackageID='" & strPackageID & "'"
'WScript.Echo strQuery
Set DPs = objSMS.ExecQuery (strQuery)
For Each DP In DPs
WScript.Echo "DP Path:" & DP.ServerNALPath
DP.RefreshNow = True
WScript.Echo "Working..."
DP.Put_
Next
WScript.Echo "Done"

 
 

April 8 2011

x86 or x64 Boot Images during SCCM OS deployment

If you are wondering which architecture of boot image to use during SCCM OSD, the following table may assist you. When picking which boot image to use, it’s important to know there are different rules for Install Packages and Images.

Use of the wrong type of boot image may result in failure of the task sequence and an error in the SMSTS.log like:

The detected setup program architecture does not match the current boot image. You must correct your task sequence so that the installation package matches the boot image.

 
 

April 5 2011

SCCM database size

I’ve never been able to find any detailed information about the expected size of the SCCM database. I decided to keep track of this during a recent deployment.

As a general rule, I had usually allowed 500MB for SCCM system database and about 2-5MB for each client that is deployed. Since there are no definative guidelines in the SCCM capacity planning documentation, I decided to closely track the database size on this SCCM deployment.

I have attached the results here – SCCM growth data.

In summary I found that you should allow 500MB for system databases, then allow 5MB for each client you are going to deploy. This number allows space for SQL data and log files. My deployment included almost all features of SCCM including OSD (many driver packages), Software Updates, approx 200 software packages and around 15 secondary sites.