July 2008 - Posts
Hi All,
Let's start by saying that this blog post is probably more OpsMgr related, but all topics are valid for a remote SQL Install for Sms, SCCM or any of the other System center products, so I guess it's still ok to post it here.
Look, I am not all that good with popular quotes, never seem to be able to remember them just right. But this is one of them that I have never had trouble remembering. "It is all fun and games until someone throws a firewall into the mix".
Not sure who the quote is from, but I am pretty sure he was refering to my lab environment. Yesterday, I redeployed my Opsmgr 2007 environment, to test the installation on windows server 2008. I figured, install a new sql server on 2008 on one machine, then install opsmgr 2007 on another, shouldn't take more than a single evening. I'll start rolling out agents and importing management packs the day after. Seemed like a plan at the time.
So I installed Asp.net, powershell, IIS, the II6 compatability tools in short all the requirements to install SQL 2005 reporting services on a Windows Server 2008 as listed here:
http://support.microsoft.com/kb/934164
Then I installed SQL 2005, the database engine and a default install of SQL reporting services, followed by applying SP2.
Next, I installed the Scom database, no problem at all, I am on a role here.
Then I started the management server and console install on the remote box. Err.
The root management server complained that it couldn't find the database. I splapped myself on the forehead, sure you silly you still need to enable The Tcp/ip protocol in the SQL Server configuration. I checked, and found that Tcp/ip was already enabled as a listening protocol.
Hum, strange, opened a dos box, and ran netstat -a -n -p tcp to see whether my sql box was listening on port 1433. Lo and behold, it wasn't. You see, I know it was something like that. Still took me a while to figure out that my SQL Server, which was running in a specific named instance was listening on dynamic ports. (If anyone knows how that could have happened just let me know).
Now, I wasn't going to let something silly as that stand between me and my plan, so I configured the SQL tcp/ip protocol for this instance to listen on port 1433, and restarted the SQL Server service as listed here:
http://msdn.microsoft.com/en-us/library/ms177440(SQL.100).aspx
I subsequently ran netstat -a -n -p tcp again and tada, the server was listening fine on port 1433.
Back to the original task at hand install the OpsMgr management server. Err.
Database still not found, ok, I am getting fed up with this, I download microsoft's portqry tool, and verified whether I could access port 1433 from the remote machine. The portqry -n sqlserver01-e 1433 came back with a response of Filtered. Another slap on the forehead, you nitwit, you have the Windows Server 2008 firewall running. So I went to the Sql box, and decided NOT to disable the firewall but to configure it to open port 1433, as described here:
http://msdn.microsoft.com/en-us/library/ms175043(SQL.100).aspx
Once done, I ran my portqry again, and it showed up as listening, great, we're back on track.
I launched the Opsmgr management server installation again, and the darn thing failed on me again.
Luckily for me the log file came around telling me that a custom action in the msi had close the handle to soon, and that it should be configured not to do that. _SetRootHealthService_Wizard unexpectedly closed the hInstall handle was the error message at hand. So after telling the setRootHealthService_Wizard that it wasn't allowed to close the handle so soon, or that I would put it in the naughty corner, I retried the installation.
Apparently my authority, that still works on my 3-Year old soon, didn't impress the setroothealthservice_wizard. In a illuminated attempt to still get this to work I went back to the Sql server box and configured the firewall to log dropped packets. Retried the installation again, which obviously failed, and went back to analyze the windows server 2008 firewall log on the sql box. This revealed dropped packets on udp port 1434. Oh, now that's easy enough to fix, let's just open that port and we're set. Erm wait a minute, I thought all sql database engine communication went over tcp port 1433, what's up with this 1434 udp port all of a sudden.
Great after having this miracle idea of deploying sql on a box with the firewall still running, I'll have curiousity kick in, this is going to set back my planning on this a couple of hours, or at least that's what I thought, but Live search and Sql Magazine to the rescue the udp port 1434 reportedly is needed to access a named instance:
http://www.sqlmag.com/Article/ArticleID/39447/sql_server_39447.html
Now, that I had settled my curiousity, I was free to open udp port 1434 in the SQL Server firewall, and retry the opsmgr root management server installation, and kadadzing the install completed with success.
--
Enjoy.
"Everyone is an expert at something"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx
http://www.linkedin.com/in/kimoppalfens
One of the customization steps no Configmgr administrator should be without, is a set of additional right-click actions.
My personal favorite set, is the set from Rick Houchins, which you can find here:
http://myitforum.com/cs2/blogs/rhouchins/archive/2008/04/09/sccm-right-click-tools.aspx
After you launch the install you need to choose between a server or workstation install
If you install the tools on the server, than the rest is simple next, next finish-follow the wizard stuff.
If you install the tools on a workstation than you still need to fill out the Site code, Site server and management point.
Once installed you will see the configmgr console tools installed in the Add/remove programs control panel snap-in
O
On the configmgr console you will see a couple of new actions availabe:
You can find these additional actions in the following spots:
- On Each collection in the tree & details pane
- On each collection member in the details pane
- On advertisement instances in the details pane
- On the Software updates nade in the tree & details pane
These tools can make the life of any sms admin a whole lot easier.
This concludes yet another step in customizing the sccm admin console.
Stay tuned, for the next post when we start doing the customization deep dive.
--
Enjoy.
"Everyone is an expert at something"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm/default.aspx
http://www.linkedin.com/in/kimoppalfens
Before beginning the upgrade process to Configuration Manager 2007 SP1, the Windows AIK 1.0 should be uninstalled from the SMS Provider computer for the site to allow SP1 Setup to install Windows AIK 1.1 to support SP1 OSD WIM images.
If the Windows AIK 1.0 is not uninstalled prior to beginning SP1 Setup, and a PXE service point is installed in the site running the Windows Deployment Services (WDS) Server service, the upgrade might fail and result in an unexpected restart and post-upgrade SMS Executive service crashes.
The following information has been added to the documentation libary for Configuration Manager 2007, but we won't be able to publish it to the Web until we refresh the documentation libary when Configuration Manager 2007 R2 is released. In the meantime, I'm making this post to give you the information that you need to successfully upgrade Configuration Manager 2007 sites to SP1 and troubleshoot an issue that you might encounter.(continue at source)
The work that needs to be done in the Configuration manager 2007 admin console is often spread out amongst different team members. Not all of these team members require access to the full admin console. Most environments do configure the permission set in a somewhat restrictive member so that team members only have the permission they need, but what is often forgotten is building a custom minimal admin console with just access to the features people need.
This shouldn't be done from a security point of view, the additional security this brings is neglectable, but more from a usability point of view. It makes the admin console easier to use, and avoids access denied errors, or empty detail panes because someone clicks on a heading in the admin console for which he doesn't have permission.
Now how do you build such a custom Configmgr 2007 admin console you might ask.
Step 1) You launch mmc.exe
Step 2) In the File menu, you select Add/remove snap-in
Step 3) Add the system center configuration manager snap-in, and select the "Select console tree items to be loaded (custom)" radio button.
Step 4) Select the console tree items you want
Step 5) Click Next, Finish and Ok, below is a screenshot of the tree pane of the custom console I created
Step 6) Select "System Center Configuration manager" in the tree pane, right-click it and select "New Window from here"
Step 7) In the File menu select options
Step 8) Name your console "Custom Configmgr admin console"
Step 9) In the console mode select "User mode - Limited access, single window"
Step 10) Clear the checkbox for "Allow the user to customize view"
Step 11) Tick the checkbox for "Do not save changes to this console"
Step 12) In the file menu save your snap-in
Step 13) In the prompt about multiple windows being open click "Yes"
Step 14) Launch your customized mmc console and verify whether everything looks according to plans.
PS: a similar option was already available in sms.
--
Enjoy.
"Everyone is an expert at something"
Kim Oppalfens - Sms Expert for lack of any other expertise
Windows Server System MVP - SMS
http://www.scug.be/blogs/sccm
Steve Rachui: Every OSD administrator knows the feeling of configuring a complex (or even simple) OSD Deployment, testing and releasing - only to have the deployment fail. At failure, OSD will begin a countdown to reboot and, on restart, the logs are often lost and we administrators are left wondering what went wrong. To find out we have to start the deployment again and spend time waiting for the failure. Wouldn't it be cool if we had a way to automate forcing OSD to collect logs when it fails before exiting? Good news! :)
I have spent some time recently working on just how to do that and we have two examples - both use the same approach but one is for generic task sequences (those sent through advertisements,etc) and the other is for OSD deployments. Lets start with the generic one, explain the needed steps and the show how we incorporate that into OSD.(continue at source)
Issue
When the Configuration Manager 2007 operating system deployment feature is used to deploy a Vista SP1 image, a new boot configuration data (BCD) store is created using the BCD template. Configuration Manager 2007 explicitly creates the Boot Manger and Operating System objects from the BCD template, but allows the Resume object to be created implicitly by Windows Vista when it goes through mini-setup. Vista SP1 correctly generates the Resume object during mini-setup but the associated Resume settings objects are not generated. Because there are no Resume settings objects, hibernate functionality does not work.
Solution
To resolve this issue, run the following script on Vista SP1 computers deployed using Configuration Manager 2007 operating system deployment to create the missing Resume settings objects. To run the script type the following at a command prompt
cscript.exe /nologo scriptname.vbs
This script can be deployed in two scenarios:
· Run as part of the Vista SP1 deployment: Incorporate the script into the operating system deployment task sequence as a Run Command Line step once the new operating system is installed.
· Run after Vista SP installation: Incorporate the script into a software distribution package/program and then advertise it to existing computers previously deployed with Vista SP1 using Configuration Manager 2007 SP1.
Code Snippet:
' Connect to WMI
set oLocator = CreateObject( "WbemScripting.SWbemLocator" )
set oRootWMI = oLocator.ConnectServer( ".", "root\wmi" )
oRootWMI.Security_.ImpersonationLevel = 3
' Connect to BCD
set oBCD = GetObject( "winmgmts:{impersonationlevel=Impersonate,(Backup,Restore)}!root/wmi:BcdStore")
if Err.number <> 0 then
WScript.Echo "ERROR: Failed to connect to BCD"
WScript.Quit(1)
end if
' Open the system store
if not oBCD.OpenStore( "", oBcdStore ) then
WScript.Echo "ERROR: Failed to open the system BCD store"
WScript.Quit(1)
end if
set oBCD = nothing
const ResumeLoaderSettingsBcdObject = "{1afa9c49-16ab-4a5c-901b-212802da9460}"
const GlobalSettingsBcdObject = "{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}"
' Check to see if the {resumeloadersettings} object already exists
if oBcdStore.OpenObject( ResumeLoaderSettingsBcdObject, objWBM ) then
WScript.Echo "Resume Loader Settings object already exists in BCD"
WScript.Echo "No changes have been made to the system"
WScript.Quit(1)
end if
WScript.Echo "Creating new {resumeloadersettings} object..."
if not oBcdStore.CreateObject( ResumeLoaderSettingsBcdObject, &h20200004, oResumeSettings) then
WScript.Echo "ERROR: Failed to create the BCD object"
end if
if not oResumeSettings.SetObjectListElement(&h14000006, Array(GlobalSettingsBcdObject )) then
WScript.Echo "ERROR: Failed to set the Inherit element"
end if
WScript.Echo "Finished updating BCD"
========
You can read the original post here. Enjoy!
Hey Guys ,
Got this from Ronni Pedersen blog and look very handy for people dealing with different keyboard/regional settings in a country like belgium.
****************************************************************************************************************************************************************************
Living in a non-english speaking country like Denmark, I often have to deal with deploying English versions of Windows XP and/or Windows Vista, with other Regional Settings, Keyboard Settings, Time Zones etc.
In the past I've created a VBScript to modify the sysprep.inf or the unattend.xml, after laying down the image on the client. The values were configured with Collection Variables or Computer Variables. The script collected the value during deployment, and replaced the value in the sysprep.inf or unattend.xml file before restarting into mini setup.
This year at TechEd in Orlando, I attened a great session on Windows Deployment with Configuration Manager (Part 1 of 4) with Michael Kelly. In this session he showed a demo, where he created a custom variable ("XRes" and "YRes"), and typed the variable direct in sysprep.inf like this:
sysprep.inf:
[Display]
XResolution=%XRes%
YResolution=%YRes%
This was a simple example, but it gave me a lot of ideas to work with. And as a result of this, I no longer need my "fancy" script to take care of my deployments anymore. This is how I do it now (example):
For my Windows XP deployments I've created a sysprep.inf that looks like this:
(This can also be done with Windows Vista deployments, but you’ll need to use the unattend.xml and the format should be in XML).
sysprep.inf:
[GuiUnattend]
TimeZone=%LAB_OSDTimeZone%
[ResionalSettings]
SystemLocale=%LAB_OSDSystemLocale%
SystemInput=%LAB_OSDSystemInput%
[Display]
XResolution=%LAB_OSDXResolution%
YResolution=%LAB_OSDYResolution%
The sysprep.inf file should be place in a package in order to use it from the task sequence.
Click to read the rest
Kenny Buntinx
The Release Candidate of ConfigMgr 2007 R2 has been posted to the Microsoft Connect site today.
SCCM 2007 R2 requires a ConfigMgr 2007 SP1.
What does R2 add to ConfigMgr 2007 as an extra :
- Application Virtualization management support
- Forefront Client Security Integration
- SQL Reporting Services Reporting - Allows you to report on Configuration Manager activity using SQL Reporting Services
- Client Status Reporting
- Unknown computer support : In Configuration Manager 2007 R2, you can deploy operating systems to computers using a PXE service point without first adding the computer to the Configuration Manager database.
- Multicast deployment :Previously, all operating system deployments used unicast. Multicast can make more efficient use of network bandwidth when deploying large images to several computers at the same time.
- Running command lines in task sequences with credentials other than the local system account.
Rgds ,
Kenny Buntinx
This article has step-by-step instructions for publishing an Internet-based site system server behind ISA, and using SSL to SSL bridging (also known as symmetric bridging). It lists the requirements for the instructions to be successful, and then takes you through the processes of creating a security group for ISA to use, deploying a client certificate for the Internet-based clients, deploying the certificates for ISA, and configuring ISA for Web publishing on ISA Server 2006. The appendixes have additional information for how to create a certificate template, the equivalent configuration steps for ISA Server 2004, and how to configure server publishing (SSL tunneling) as an alternative solution to SSL bridging. Kenny Buntinx
Hey ,
I already wrote a previous blog post about this marverlous problem that al the sudden you can't boot anymore from PXE . It says PXE-T01 No boot File found . If you dig deeper into the c:\windows\temp folder there is a hidden PXEBootfiles folder to see...
The problem were goofy ACLs on the c:Windows\temp\pxebootfiles. When I attempted to revised security, I got an Access is Denied message. Once the above directory was deleted, the SMSBoot folder would populate when the bootimage was refreshed on the PXE point. If you get this error, you need to locate the folder (it is hidden), take ownership of it, and delete it. The folder will be at %temp%/PXEBootfiles.
This worked BEFORE SCCM SP1 !!
After I applied SP1 @ customer site , it did not work ... What the hell ?
The solution was simple & logic , but hard to find out why :
If you put an operating system image an select the SMSPXEIMAGES$ Distribution point instead of the normal Distribution point , you will receive an access denied error and the ownership on the %temp%/PXEBootfiles is taken by a goofy SID account that does not resolve. The error occurs because the permissions from the WIM file are applied to the PXE temp folder used for extracting binaries, and the logged in user does not have permissions to delete those folders. Therefore, the PXE service point fails to extract binaries because it cannot delete or access the temp folders for extracting purposes.
Make sure that you do not have an OS Image or OS Package being distributed to your \\YOURSERVER\SMSPXEIMAGES$ ! After this step you need to locate the folder (it is hidden), take ownership of it, and delete it. The folder will be at %temp%/PXEBootfiles.Restart the WDS services and the SMSBoot folder would populate automaticaly.
PXE boot will work again!
Kenny Buntinx
Microsoft has launched an new article around this . See my previous posts regarding MDT2008 (http://scug.be/blogs/sccm/archive/2008/05/17/installing-osd-deployment-with-mdt-2008-and-get-an-error-in-sms-provider-log-during-mdt-ts-import-custom-boot-image.aspx)
See http://support.microsoft.com/kb/950782/en-us for the full article
To replace Windows AIK version 1.0 with Windows AIK version 1.1, follow these steps:
1. Uninstall Windows AIK 1.0 by using the Add or Remove Programs feature in Control Panel, and then restart the operating system.
2. Install the latest version of Windows AIK. For example, use the Waikx86.msi installation file.
3. Export the boot images from Windows AIK. To do this, follow these steps:
a. Click Start, click Run, type Wbemtest.exe in the Open box, and then click OK.
b. Click Connect.
c. In the Namespace field, type root\sms\site_site code, and then click Connect.
d. Click Execute Method.
e. In the Object Path field, type SMS_BootImagePackage, and then click OK.
f. In the Method field, select ExportDefaultBootImage, and then click Edit In Parameters.
g. Under the Properties field, click to select the Architecture check box, and then click Edit Property.
h. Next to the Value field, click to select the Not NULL check box, type x86 or x64 under the Value field, and then click Save Property.
i. Under the Properties field, click to select the ExportImagePath check box, and then click Edit Property.
j. Next to the Value field, click to select the Not NULL check box, type the path of the image under the Value field, and then click Save Property.
k. Under the Properties field, click to select the ImageIndex check box, and then click Edit Property.
l. Next to the Value field, click to select the Not NULL check box, type 1 under the Value field, and then click Save Property.
m. Click Save Object.
n. Click Execute. After some time, a dialog box that indicates success appears.
4. In the Configuration Manager console, import the image to System Center Configuration Manager. To do this, follow these steps:
a. Under System Center Configuration Manager in the Configuration Manager console, expand Computer Management, expand Operating System Deployment, expand Boot Images, and then click Add Boot Image on the Actions pane.
b. Supply the location and the name of the new boot image that you specified in step 3j for the ExportImagePath value, and then follow the instructions in the wizard to add the boot image.
5. Verify the version of Windows AIK. To do this, follow these steps:
a. Click Start, point to All Programs, point to Microsoft Windows AIK, and then click Windows System Image Manager.
b. Click Help, and then click About.The build number for Windows AIK version 1.1 is 6.0.6001.18000.
Kenny Buntinx
Got this one from Brett Flag - OSD team Microsoft :
SCCM defines a driver as an INF file plus its associated content. When a driver is first imported we do a check to see if the exact same driver (e.g. same INF file and content) has already been imported at the site and prevent it from being imported. However, if there are any differences then the metadata is read from the INF file (including name, manufacturer, supported operating systems, etc.) and a new driver object is created.
It is not uncommon for hardware vendors to package different INF files for each operating system they support in the same directory. When this happens, SCCM will create a driver object for each INF file but it is smart enough to only keep a single copy of the content. Since the default name of a driver comes from the supported hardware list in the INF file, each of these driver objects will likely get the same default name even though they support different operating systems (to see if this is the case, check out “Applicability” tab on the Driver’s preview pane).
There are a few things you can do about this:
- SCCM generates a default name for a driver based on the hardware that it supports – but you can change this in the driver’s properties screen.
- Add additional columns to the Drivers view so that you can tell the difference between the drivers:
- Select the Drivers node in the Admin UI
- Run the View - Add/Remove columns… action
- Select additional columns to display (for example “INF File”)
- Ignore it – Since SCCM automatically determines driver applicability at deployment time you don’t really need to worry about the specific drivers in the driver catalog.
After importing a driver you can review the driver catalog matching reports (“Driver catalog matching report for a specific computer” and “Driver catalog matching report for a specific collection”) which use hardware inventory information to predict what drivers match devices in your environment to give you a better idea of how the drivers will be used.
Thanks Brett ...
Regards,
Kenny Buntinx
Today I used my new OSD deployment package in SCCM with XP SP3 and when I wanted to "Prepare my OS" the task sequence always failed with errorcode 0x08000002.I was figuring out what the hell was going on and then I found it . For XP SP3 you will need the updated "Deploy.cab" with sysprep.
There have been changes to sysprep in XP SP3. I have updated my pages to reflect this but the issue deals with the default profile and it no longer being copied when running sysprep. Before SP3 and without the patch the default profile was copied from the administrator account during the sysprep process, this behavior however changed in SP3 or when you installed the hotfix 887816. In SP3 the default setting is to not copy the default profile, thus a new key was added to sysprep.inf to allow for this functionality. The UpdateServerProfileDirectory=1 setting tells SP3 to copy the administrator profile to the default profile during the sysprep process.
Hope it works out for you ,
Kenny Buntinx
This post and subsequent posts will be a step by step on how to build a base XP SP3 image in SCCM. I will be outlining not necessarily pointing out every click. Hopefully others will find this helpful. This assumes an understanding of SCCM and uses what is refereed to as a “Thin Image Strategy”.
- Create a network access account, it only need be a domain user and its password should not expire. Add the account to the Computer Client Agent in the Client node under Site Settings
- Import XP SP3 as an operating system Install Package.
- Add a Distribution point to your new XP SP3 package created in step 1
- Create the XP SP3 sysprep package in SCCM
- The Deploy.cab included on the CD was not updated properly for XP SP3 so you must download a new version here.
- Create a package that points at the extracted CAB file for its source
- You do not need to create any programs for the package the build task sequence takes care of this
- Add the package to a DP that can be used during your build
- Create a package for the Config Mgr Client
- Specify always obtain file from source directory
- Usually here I create a share at \\SCCMSERVER\Souce$\SCCMClient.
- Update the ccmsetup command line properties accordingly. Extensive information about command line properties on TechNet here.
- Add the package to a DP that can be used during your build
- Create a “Build and capture a reference operating system image” task sequence
- Name the task sequence something appropriate like “Build & Capture Windows XP SP3 Gold Image”
- Select the x86 boot image
- Select the Operating System Package you created in step 1
- Enter a product key
- Set the local admin password to any password
- Join a workgroup
- Select the Config Mgr client you created in step 4
- Don’t add any software to the base image
- Set your image properties
- Select a location to save the image and make sure you include the full path including the .wim extension
- Enter an account with rights to write to the share
- Finish up
- Change the task sequence to use “Quick Format”
- Right Click on the Task Sequence and choose Edit
- Select the “Partition Disk 0″ step
- Choose properties on the Default (Primary) partition and check the “Quick Format” option
- Create a collection to which you will advertise the task sequence; I usually use "customer" Base Builds
- Advertise the task sequence to the collection you created in step 7 as optional
- Right click Task sequence and choose advertise, follow the wizard
- Make sure you select the check box “Make this task sequence available to boot media and PXE”
- If you are in test and your boundaries are not defined make sure you select “When no local distribution points are available, use remote distribution point”
- Make sure you completed step 1
- Ensure that you have the network and mass storage drivers to boot the device on the boot image and in the driver store (If you have to do this in the future you must update the PXE and standard DPs)
- Add the appropriate boot images (x86 / x64) to the PXE and standard DPs
- Allow the client to boot from PXE
- If this client previously had an SCCM agent on it you just need to add the client to the collection you created in step 6
- If this is a new client and SCCM is pre-R2 add the client manually
- Add the client by right clicking the Computer Associations node under OSD and choosing “Import Computer Information”
- Enter the Name of the computer
- Enter the MAC and or SMBIOS GUID
- Add the computer to the collection you created in step 7
- Boot the device up to PXE and choose your task sequence. In less than an hour you should have the start of a great XP Image
Kenny Buntinx