While answering a forum post I was reminded that SQL Reporting Services 2008 no longer requires IIS (see http://blogs.technet.com/andrew/archive/2007/12/04/sql-server-2008-reporting-services-no-longer-depends-on-iis.aspx for a good post on this). Thus, when rebuilding my ConfigMgr lab recently, I decided to use SQL 08 and SSRS 08 on Windows Server 08. The only notable thing, IMO, is that the configuration tool for SSRS 08 is a little more straight-forward and gives better explanations than the one in SSRS 05. They are actually very similar, so maybe it’s just because I’m used to the one in 05 now, but the first time I opened the one in 05, I had no idea what to do.
In the end, everything went as expected. SSRS installed fine (no IIS), the SRS Reporting Point installed without a hitch, the reports transferred quickly, and most importantly, all the reports worked – at least the ones I tested. Now granted, this is my home lab, but I didn’t see anything that should cause anyone any issues. Also note that the Windows firewall is enabled on all of my systems – SQL Server, ConfigMgr Site Server, Domain Controller, and clients; I actually force it to be on using a GPO. So, anyone who thinks that they need to turn it off, needs to reevaluate (maybe another post on that is in order).
As a discovery exercise, I created a small, stand-alone app using AutoIT that displays a dialog box with the current value of the environment variables USERNAME and USERDOMAIN, and then waits for the OK button to be pushed. I then added this app to a ConfigMgr package and called it using a command-line task in various places in a task sequence. Here are the results using just a basic deployment task sequence:
Before PE
Launching the application via a TS advertisement before the initial reboot into PE stopped the whole TS flat. The message box was launched as the local SYSTEM on a different window station and thus wasn’t shown on the current users desktop. My only option was to kill it using Task Manager which caused the whole TS to fail because a failure code is sent back to the TS.
After PE, Before Image deployment
In this one, the app launched as the local SYSTEM and showed up on the PE desktop fine. The TS waited for me to click OK before going on.
After Image Copy, Before Mini-setup/OOBE
Not surprisingly, this step resulted in the same thing as the last one as we are are still in PE and nothing has changed.
After Mini-setup/OOBE
This is the last one I tested and gave weird results. At this point in the TS, we’re actually in the OS deployed and not PE. The message box appeared just fine, but the environment variables I was keying on didn’t exist (I confirmed this by pressing F8 and reviewing the output of the set command). I’m assuming this is still the local SYSTEM account, but my current method doesn’t prove that one way or another; I need to find a new way to check for the user context and re-run this step of the test.
Next Step
The next step is to test these same variables when running the app using a Software Install task and maybe to find a better way to report the current user context. All that in a future post.
I’ve updated my OSDAppChooser app to include a requested feature. Basically, someone requested the ability to have all applications chosen to be installed by default instead of no applications chosen. Thus below are the changes. Installation and usage instructions have not changed so please refer to the original post for those: OSD Application Chooser.
Added features:
- Global Applications: These applications are added to the list of every application set. Use a GlobalApps tag to enclose them in the XML configuration file.
- Select All Applications: Select all applications in a chosen Application Set. A new property of the OSDAppChooser top tag was added to configure this option: selectAll.
- Select Specific Applications: A new property was added to each App tag: select. This controls whether or not it is selected for installation by default or not.
The example configuration file included in the new zip has examples of all of these.
I’m going to add the ability to have mandatory applications also but I can;t find a good way to represent them in the GUI. The best way would be to add the items to the list view but disable them, alas, the Windows built-in list view control does not have this ability so I need to explore other ways to show them. This isn’t a critical feature because it can be accomplished directly in a TS, but I think it does add value and have some benefits over putting it directly in a TS.
Today, I visited a customer that I had installed an evaluation version of Configuration Manager at. 120 days passed a couple of weeks ago and now it was time to convert the evaluation into a full version.
Simple process really, insert CD, run upgrade … watch LUN on iSCSI storage array hosting the dynamically expanding VHDs fill up and cause the VM to stop cold. Hyper-V saves the state of the VM and marks it as critical, so no big deal, we just expanded the LUN. Unfortunately, in the process, the VM got powered off.
So, after expanding the LUN, we restarted the upgrade. Everything looked good -- i stress “looked”. I created a new package, pushed it out to a test machine, and went to lunch. When we came back, the package deployed successfully, but I didn’t have any status for the new advertisement. Something was definitely wrong.
The compmon.log had the following over and over:
Can not get the current execution state for component SMS_SOFTWARE_INVENTORY_PROCESSOR since it is not installed or completed installing.
Can not get the current execution state for component SMS_INBOX_MONITOR since it is not installed or completed installing.
Can not get the current execution state for component SMS_DISCOVERY_DATA_MANAGER since it is not installed or completed installing.
Can not get the current execution state for component SMS_STATE_SYSTEM since it is not installed or completed installing.
Can not get the current execution state for component SMS_LAN_SENDER since it is not installed or completed installing.
Can not get the current execution state for component SMS_INVENTORY_DATA_LOADER since it is not installed or completed installing.
Can not get the current execution state for component SMS_WSUS_SYNC_MANAGER since it is not installed or completed installing.
Can not get the current execution state for component SMS_MP_FILE_DISPATCH_MANAGER since it is not installed or completed installing.
Can not get the current execution state for component SMS_SOFTWARE_METERING_PROCESSOR since it is not installed or completed installing.
Can not get the current execution state for component SMS_SCHEDULER since it is not installed or completed installing.
Can not get the current execution state for component SMS_STATUS_MANAGER since it is not installed or completed installing.
Not good. First, I tried a site reset, no change. Then I tried the upgrade again, same thing. Time for more log spelunking.
The sitecomp.log had the following message for each of the above components:
Installed service SMS_SERVER_BOOTSTRAP_SPFM-CM-01.
Starting service SMS_SERVER_BOOTSTRAP_SPFM-CM-01 with command-line arguments "SPF C:\Program Files (x86)\Microsoft Configuration Manager /deinstall C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\perfsetup.exe SMS_WSUS_SYNC_MANAGER"...
Execution of "C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\perfsetup.exe /deinstall /siteserver:SPFM-CM-01" on server SPFM-CM-01 failed: Child process exited with non-zero code 1000.
Bootstrap operation failed.
Deinstalled service SMS_SERVER_BOOTSTRAP_SPFM-CM-01.
Bootstrap operations aborted.
Reinstallation failed and will be retried in the next polling cycle.
Web searches at this point turned up nothing in particular. I did find a KB with a hotfix that was a stab in the dark: 954214. No change after installation.
I had looked through the Windows Application event log a few times before but didn’t act on anything there. I tried running the command line given in the sitecomp.log file manually and noticed that it created errors in the App log, so now it was time to look at them. The errors cam in pairs:
LoadPerf 3011: Unloading the performance counter strings for service SMS_LAN_SENDER (SMS_LAN_SENDER) failed. The first DWORD in the Data section contains the error code.
LoadPerf 3012: The performance strings in the Performance registry value is corrupted when process Performance extension counter provider. The BaseIndex value from the Performance registry is the first DWORD in the Data section, LastCounter value is the second DWORD in the Data section, and LastHelp value is the third DWORD in the Data section.
Aside from the confusing English of these messages, I might have my culprit, corrupt performance data. Why this would cause the issue, I have no idea. I also checked PerfSetup.log and noticed the following, similar, errors.
Error: UnloadPerfCounterTextStrings failed with command line 'Application SMS_LAN_SENDER' to unload performance counters; error = 1010 (0x3f2).
After a couple of web searches on LoadPerf 3011, i found the following command that resets performance counter data:
lodctr /r: c:\windows\system32\perfstringbackup.ini
Amazingly, this worked and now all is good and right with Configuration Manager (again). I have no idea why corrupt performance counter data should cause such issues, but it did.
Microsoft just released a new hotfix that allows you to suppress the plug and play UI in Windows XP and Server 2003: http://support.microsoft.com/kb/938596. I haven’t played with it yet, but it sounds like it has potential when deploying new systems using ConfigMgr or MDT. Sometimes, there’s that one device you either don’t care about or can’t find a driver for that just pops up over and over again but doesn't change anything on the system. Or, if your users don’t have local admin privileges (which they shouldn’t), if a new device is available on the system, you can now hide the UI. Not sure of all the useful scenarios, but definitely some potential.