May 2007 - Posts

The next logical question in my client saga is; Just when does that client try to initiate a repair?

Turns out,as you might guess, that there are a host of reasons:

1. CCMEXEC tries to connect to the root\ccm WMI namespace. If the namespace does
not exist, it will flag a repair.


2. CCMEXEC tries to open the key
HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\Performance for reading.

a) If it succeeds and the value PerfCorruptionDetected exists under
HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\Performance, it won't flag a repair.
(Setup will create this value if it detects that the performance counters are
corrupted by an application other than a failed OS upgrade or a co-located
installation).

b) If it fails to open HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\Performance, it
will flag a repair.

c) If it successfully opens HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\Performance
but the subkey CcmFramework does not exist, it will flag a repair.

 

3. CCMEXEC calls MsiEnumClients() to find all products in the MSI database that are
using a known CCM component - {8B8DEDE2-A4E4-4182-971B-96B4322F9803}.

b) Next, CCMEXEC connects to the root\ccm WMI namespace and runs 'select * from
CCM_InstalledProduct where ProductCode = 'xxx'" (xxx is the ProductCode it got from
MSI). If it doesn't find a match, it will flag a repair.


4. At last, CCMEXEC checks to see if the file cpapplet_ps.dll exists. If the file
exists, NTFS is in use and there's either no security set on the file or there's
not an ACE for the interactive user on the file, it will trigger a repair. Certain
OS upgrades will fall under this category.

Posted by pwstrain | with no comments
Filed under:

One of the things I'd like to do is feature blogs that I frequent that may have missed the attention of the myITforum faithful. I could do far worse than to start of with Lynn Lunik's blog at itprosecure.com. Lynn is a former Microsoft Consultant who's now gone on to found IT Pro Secure Corporation.

I attended a seminar Lynn gave on SCOM and he is hands down one of the most knowledgable guys in his field in my area. His blog (which is actually here and the rss feed is here) is a regular offering of updates, links, tips, and walk throughs that is not to be missed. Highly recommended.

Posted by pwstrain | with no comments

So when we made the big switch from Zenworks to SMS, we were in what I thought was a uniquely ironic position. We planned to use Zen to roll out the SMS client, then use SMS to remove Zen. There was something satisfying about that plan. Except, well, for the execution.

We pushed the SMS Client from our common software installation drive X:. That went great. We ran the client.msi from the S:\SMS_Client share and things went great. Clients started reporting, inventory started coming in. Great!

 Then we removed the Novell client, and Zen, and started to really use SMS. To depend on it.

And noticed that clients were failing. And failing to repair. The error in repair log said, essentailly (and I'm paraphrasing here): "Hey! I can't find client.msi. I installed it from x:\sms_client. Tough luck!"

Of course we had made sure to replicate our x: software installation folder, this time in DFS instead of Novell. So when a user ran "repair" from the control panel, it worked fine. But auto-repair still wouldn't work. Turns out that the auto-repair function runs in System mode. So in 'system' mode there was no S: drive. And the SMS client appears, at least in our environment, to need to repair a lot.

It looked like we were going to have to push the SMS client again. I wasn't thrilled with the prospect. If we were in a simple one location environment it's no problem, we could push the client from the Primary site Server. But with numerous locations in numerous offices of varying connectivity, this wasn't really an option. And creating an MSI to push it out via GP didn't appeal to me either. The client was already on the workstations. Couldn't we just fix it?

Well it was a simple matter to give "Domain Computers" the rights to the DFS share, but this wouldn't map a drive. Where did the client get this mysterious "source list" that it used to try and repair? From MSI.If you go look at the reg key here: hklm\software\classes\installer\products\ 17E5DA380C0881846B4EAC62706B1A14 and in the Net subkey you'll find the path from which you installed the client.msi. In our case it indeed pointed to X:. A quick change of that key to point to the path of the msi via dfs \\unc naming, and viola! The auto-repair worked like a champ. Now a quick script via either vbs or cmd to load the reg setting change during login and our problem is solved.

I know some will say this may cause problems in the future. But for us, any update to the client will most likely be either from the same share or via SMS package. The same share is no problem, and an SMS package will re-write the location of the client.msi anyway.

Lesson learned (in this case, re-learned): always be aware from where you install your msi files, or use the /source switch to tell it where you want it to point for the msi if repair, re-install, or uninstall is intiated.

 

 

Posted by pwstrain | 2 comment(s)
Filed under:

My notes from MMS.

MMS : Day Four

Today begins with a great keynote session involving a breakout discussion among four major CIO / IT Manager types : Carnival Cruise, Dell, EDS, and Virgin. The discussion around their needs and different environments, and how they are each using the System Center product line, provided a lot of insight into what going on in the real world.

We had the discussion that, five years from now, System Center will be the product line everyone is using in the management space. I'm not even sure that catch-up is the right term for what everyone else will have to do. Interoperate is more like it.

Then it was off to the 911 Case Studies session. Best session of the week by far. Finally, a chance to get in front of an SMS Support Engineer and delve into real problems that affected real people. The case studies were great, the support tools presented were well displayed. Can't say enough about how good this session was.
Looking forward to Assett Management and Internet Client Management after lunch.

UPDATE: Let me just say it now: Service Manager is going to rock. If the pre-release stuff looks (and works) this well, the final product is going to be great.
With auto-incident creation, deep hooks into SCCM07 and SCOM07, Service Manager is going to be the asset / incident / change manager of choice for many, many companies. Can't wait to get me hands on the next beta.

UPDATE: The next item to get a round of applause (and a "That's TechSexy!" from someone) was Internet Based Client Management. This is something that has been plaqueing our company for years now. What do you do when a laptop user doesn't come in the office for two months? How do you distribute new software, patch the OS, etc? We finally have an answer in the Internet Based Client in SCCM07. This is just going to be a HUGE help in our environment.

Posted by pwstrain | with no comments
Filed under:

My notes from MMS.

MMS : Day Three

Day three and we have sunny skies, less wind, and real bacon for breakfast. Not a bad combo.
I'm idle until 10:15, so catching up on some work and correspondence. I'm currently torn between the "Deploying Config Manager 07" and "Intro to Ops Manager 07" sessions. Leaning towards the Ops Manger.
The Config Manager Deploy is a Hands-On-Lab, and while nice, they do leave a bit to be desired. Step-by-step installs aren't what I came hear for. I can run through the lab on my own in the big hall later.
I'm chomping at the bit to get home and implement my lab and start testing against a backup of our DB.
More as it happens.
Update: Well Deploy Config Manager session 2 was a bust. Spent most of the session going over stuff that was covered in session one, and then watching install screens snooze by. I walked out to use the restroom and passed no less than four people asleep.
We come to these things for the deep dive, the technical specifics. If someone wasn't at the first session, they can catch it on the DVD. The info was fine and the speakers were good, they just spent too much time covering territory that was already covered, either yesterday or in labs. Deploy multiple secondary sites and DP's! Upgrade the MMS client network!
DO something not in VM? What a concept!

Posted by pwstrain | with no comments
Filed under:

My notes from MMS.

MMS Day Two


Another long day.... and night. It's a good thing that there's a Starbucks in the convention center. The one tool no one tells you about is caffeine. Use it liberally.
I participated in an excellent 'focus group' today on documentation. Everyone was vocal and gave Microsoft excellent feedback. The consensus was to make "documentation" more dynamic, more easily updateable, and perhaps even available via RSS.
I think everyone agreed that making Support-level documents available, even if it was via paid subscription, would be an invaluable tool. How many times have you called support and had to get to the guy at level 3 just to get the right documented answer? Just let me at that database! I'd be thrilled to pay for it as part of my VLA, or SLA, or whatever they're calling it today.
The new SCCM07 console is much, much improved. I've never seen a bunch of grown humans more excited over drag and drop functionality. And it was interesting to note that PKI was required to deploy internet-facing SMS functionality, something we're dying for. So PKI now gets added to this summer's hit list.
I missed the IT Forum party, much to my disappointment. I used the time in the open labs, hitting a couple of the scenarios I haven't had a chance to look at yet. It would be fabulous if all of these VM's were available for take-home, so we could pass these labs on to our peers back at the office.
Tomorrow: Vista Deployment, SCOM, and Microsoft Communities.

Tags:
Posted by pwstrain | with no comments
Filed under:

MMS

So I know that MMS is long since over, but thought I’d post some notes I took at the time anyway.

 

MMS : Day One


Here in scenic San Diego for MMS. First day was long, but worthwhile.
The walk from the hotel to the event is not too bad, a bit less than a mile. The hotel, while costing $249 a night, sticks you for another $10 per day for internet access. This is ridiculous. You're the official hotel for an event where thousands of geeks are getting together, and you want to hose us another $10 for internet? That nearly every other hotel gives away for nada? Give me a break.
PdaNet works like a champ, and that's what I'll use for the duration.
And while I'm on my soapbox, you don't put out food and drinks at the convention center and then force about 70 fat IT guys to stay away for 15 minutes until you "open". There was nearly a stampede. And the food was not worth the wait. C'mon, Micro$oft. The group attending this event spends hundreds of millions on your products, and everyone that didn't get a voucher is about $5000 out of pocket for travel, hotel, and conference. Just keep the food / beverage tables stocked and open. I ended up wolfing down a mediocre turkey sandwich and Diet Coke to get to my next session in time.
So far the sessions have been very worthwhile, the best of the day being 'DeMystifying SQL" about creating custom queries / reports in SMS / SCCM. Very well done.
The Expo Center opened this evening and the crowd press was insane. The food was good and well spread-out, but you couldn't move. Popular booths were hard to get into, and the MyITForum booth was the worst. It was five deep for most of the night. I'll be getting more time with vendors later in the week. Tonight was about the food and the swag, and I got plenty of both.
More tomorrow : first keynote and community seminar.

Tags:
Posted by pwstrain | 1 comment(s)
Filed under:

WOL

SMS 2003 and Wake on Lan


One of the things we've missed after moving from Zen to SMS 2003 is Wake on Lan. For those of you not in the tech world, this gives us the ability to remotely turn on a computer using it's network connection. It's endlessly handy for patching and other things that might take a while, or just need to be done after hours.

I was flabbergasted to learn that SMS 2003 did not have Wake on Lan built in. The next version, System Center Configuration Manager, does have it. We've had WOL in Zen for years and years.

There are companies that offer WOL capabilities as an add-on to SMS. But another client on the workstation and another expense are just out of the question.

So there are some great contextual add-ons for SMS that are free, and one of the was Wake-On-Lan. Hooray!

Alas, the wake-on-lan only worked on it's own subnet. Not good enough for me.

I found a free WOL utility from SolarWinds that purported to be able to WOL across subnets. I tried it out and it worked like a champ. But could it be scripted, in the same way that the contextual add-ons scripted the other utility?

A quick reg check and I found the portion where the other utility enumerates it's command line to link into the magicpacket program. A simple edit of that reg key yeilded a working result. Here's the exported .reg for the edited key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{4D26C0D4-A8A8-11D1-9BD9-00C04FBBD480}\Extensions\SMS_Tools\310]

"Description"="Use the SolarWinds WOL to wake up the client."

"CommandLine"="cmd /C \"c:\\Program Files\\SolarWinds\\Free Tools\\WakeOnLAN.exe\" -IP ##SUB:IPAddresses## -MAC ##SUB:MACAddresses##"

"CriteriaMessage"="Unable to find ##SUB:MACAddresses##"

"Name"="WakeUp""CriteriaQuery"="select * from SMS_R_SYSTEM where ResourceID = ##SUB:ResourceID##"

So with the SolarWinds Wakeonlan.exe installed in the default location, I get Wake On Lan capability across subnets from the SMS console for free.

Posted by pwstrain | 4 comment(s)
Filed under: ,