Sequencing Google Chrome

After trying unsuccessfully to Sequence Google Chrome several times, I have finally figured out the recipe.

The SCCM Advertisement Report for would report success with a last status message stating "Virtual application package registration succeeded"; however, when launching the application on the workstation I would get Error code: xxxxxx-xxxxxx24-0000010B  "The directory name is invalid".  A number of on-line sources mentioned to edit the .osd file and change the working directory or to look for short file names.  None of these led to anything helpful.  But, thanks to the instructions laid out here (http://blogs.ethz.ch/jlaville/2009/01/18/how-to-sequence-google-chrome-for-app-v-45/#comment-4998)  I was able to get it properly sequenced.  Here's the general recipe:

1. Copy install media to c:\Install\
2. Create Q:\Chrome.001
3. Run Sequencer

1. New Package

4. Package Name = Chrome.001
5. Click Begin Monitoring and select Q:\Chrome.001 when prompted
6. Install Google Chrome

2. Close Chrome and then stop the GoogleCrashHandler.exe process.

7. Move install to Q:\ (This needs to be done because App-V applications need to be installed to Q:\, but Google Chrome installs to the User profile.  Thus to properly capture the install we need to move the files.

3. Move %username%\Local Settings\Application Data\Google to Q:\Chrome.001\Google
4. Modify Chrome Shortcuts to point to the new Q:\ location

8. Launch and Close Chrome
9. Stop Monitoring

Scripting Challenge - Not So Unique Drivers

I was trying to copy a file to every sub directory in a directory that had an *.inf file in it.  This proved to be more complicated than it should be when I needed to factor in UNC paths as well as a drive mapping.  Here's the cmd file I ended up with.

cls
@echo off
:findmodel
cls
echo.
echo.
set /P model=[What is the model of the device you are using?]

echo.
echo.
set /P directory=[What directory are you searching?]
echo.
echo.
echo.
echo You are about to copy %model%.txt to all directories in:
echo %directory%
echo that contain an inf file.
echo.
set /P ready=[Are you ready to proceed? (y/n)]
if /i %ready%==y goto proceed
if /i %ready%==n goto findmodel
goto end
:proceed
for /F "delims=+ tokens=*"  %%a in ('dir /AD /s /b "%directory%"') do (
rem for /F %%a in ('dir /AD /s /b "%directory%"') do (
 if exist "%%a\*.inf" (
  echo %model% > "%%a\%model%.txt"
   ))
echo %model%> "%directory%\%model%.txt"

:end
Echo File copy should be complete.
pause

SCCM Upgrade Fight

Here's the forum post that details the struggle we encountered when upgrading to SP2 for SCCM 2007. http://www.myitforum.com/forums/m_212587/mpage_1/key_/tm.htm#212746

It's hard to get good help during the Holidays, but a little guidance and we were able to get going in the right direction. Thank you to Mr. Pherson for working so hard to resolve this issue.

Here's the details:

We installed Service Pack 2 to our SCCM environment two days ago. Since rebooting the server after the install, we have only received 4 hardware inventories (at this point, it should be about 6,000).

We have tried forcing full hardware inventories on both the old SP1 clients and updated SP2 clients. All clients seem to successfully complete the inventory, and their InventoryAgent.log shows a "Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: …" entry. I believe this means the client thinks it successfully sent the inventory to the Management Point.

However, on our site server (our only Management Point), the dataldr.log and MP_Hinv.log files don't show anything from the client, and no updated inventory data appears for the machine.

Since we noticed this problem, we went back and restored our customizations to the sms_def.mof and configuration.mof files. We have forced full hardware inventories. We've restarted the SCCM services on our site server, and rebooted it twice.

Other functions seem to be working fine. We can create advertisements which the clients see and run. Workstations are registering heartbeat discoveries. Our OSD task sequences can for build/capture and deploy both work.

In the SCCM and Server logs, the only new error we're seeing is an EventID 7102 from the SMS_MULTICAST_SERVICE_POINT every hour, which I don't believe is related.
"On 12/30/2009 1:16:11 PM, component SMS_MULTICAST_SERVICE_POINT on computer reported: MCS Control Manager detected MCS is not responding to HTTP requests. The http error is 401."

...

The basic outcome of doing the hardware troubleshooting is:

On the client:
-InventoryAgent.log shows that it successfully completed the hardware inventory and says it successfully sent the report to the MP

On the SCCM Site Server / Management Point:
-Neither the dataldr.log or MP_Inv.log files show anything from the client.
-There are no inventory errors shown in the ConfigMgr Status Message Viewer. The only error we're seeing is from the SMS_MULTICAST_SERVICE_POINT mentioned in the first post.

...

We reinstalled the Management Point, and then reinstalled BITS on our Site Server. Hardware inventories have been rolling in over the past week.

The long story:

The first thing we did was assign a Management Point role to one of our Distribution Point servers. After the install was complete, we changed the 'default management point' to the other server (Under Component Management, on the properties page for the Management Point Component you can set the default management point to any server with the Mangement Point role installed). Shortly after doing this, we started seeing updated hardware inventories. This confirmed were were heading in the right direction.

We started to remove the Management Point role from the Site Server. However, we were too jumpy... we didn't wait to see the role get uninstalled in mpsetup.log and just assumed it was done because it was gone from the console. (Learning point: You should see the uninstall in mpsetup.log and if you watch you ConfigMgr Status message Viewer for your site. Other components will be uninstalled first, so you won't see the MP component uninstall right away.) After a couple reboots, we were able to cleanly get the MP role uninstalled. Once uninstalled, we re-added the management point, and we watched the logs until it was complete.

Unfortunately, we were still not seeing Hardware Inventory come through. (I'll edit this post later if I can find the exact log entry again, but there was an error somewhere about creating the CCM_Inbox in IIS which pointed to something about BITS)

Out next step was to try to reinstall BITS. We uninstalled BITS on our Site Server, rebooted, and then reinstalled BITS. Once we confirmed that BITS was completely set up, we changed the default managment point back over to our Site Server. And then? Yep, we started getting our hardware inventories again.

At this point, the only Error we were still seeing for our SCCM infrastructure was the Multicast Service Point error, which apparently had nothing to do with what was causing hardware inventory to fail. Luckily, this was an easy fix.

Component: SMS_MULTICAST_SERVICE_POINT
Message ID: 7102
Description: MCS Control Manager detected MCS is not responding to HTTP requests. The http error is 401.

We went to the DP component on our Site Server, unchecked "Enable Multicast", watched the satus message viewer for "SMS Site Component Manager successfully deinstalled this component from this site system" from the SMS_MULTICAST_SERVICE-POINT (and waited 15 minutes). Then, we enabled re-enabled multicast on the DP. Once it reinstalled the component, the error message did not return.

Hyper-V

You should be aware that on some older hardware when you install Hyper-V and it modifies the boot sector that it can make it so the physical hard drive isn't found and won't allow you to boot to the Parent machine. This can be fxed by using bootsect.exe from a WinPE boot device. http://technet.microsoft.com/en-us/library/cc749177.aspx

I wish I knew this before I needed it.

Hyper-v NIC’s

When setting up Hyper-V in Windows Server 2008 you need to setup network adapters for your virtual machines via the Hyper-V Network Manager (or during Hyper-V setup). The creation of these virtual network adapters will turn the adapters on the physical host into virtual switches and create new adapters on the physical host. The new adapters can actually be disabled if you don’t want the host to use them.

Example 1:

I setup a server with Windows Server 2008 running Hyper-V with three virtual servers running on it. The physical box had 4 NICs and I wanted one dedicated to the host system, and one dedicated to each of the virtual servers. On building the host I had Network Connection #1, Network Connection #2, Network Connection #3, Network Connection #4. After setting up the three virtual network adapters for Hyper-v: Network Connection #1 has no change, but Network Connection #2, #3, and #4 now didn’t have IP v4 or IP v6 selected and were acting as virtual switches. Additionally, there were new network adapters listed on the host. I disabled these new adapters because the host didn’t need to use them. The VM’s each had a NIC in their OS that got an IP address, but that didn’t mean that the host needed an IP on that adapter, because the VM is using the virtual switch and technically the additional adapters (the ones I disabled) were also using the virtual switch.

Example 2:

You could actually use this feature in a really cool way. Setup a server with Hyper-V and disable all network adapters on the host, then allow the VM’s to have access to the virtual switch so the VM’s can get out to the network. This way you could run multiple OS’s on a host server that never touched network. The host is protected and the VM’s can have a snapshot taken and reverted to a known working state when needed.