Sherry Kissinger at myITforum.com

Internet Explorer, Right-click 'Convert to Adobe PDF' Fails - Adobe Acrobat 8.1.1

Product: Adobe Acrobat Pro 8.1.1

Symptoms: In Internet Explorer, with Adobe PDF integration enabled, right-click on a web page and choosing "Convert to Adobe PDF" does nothing.

Cause:  Actually, not 100% sure on what the cause really is, but in testing of machines exhibiting this problem, it seemed to be centered around "Adobe PDF Content Menu Helper", which is an ActiveX control with AcroIEFavClient.dll. On some machines, the option was missing completely, and would not appear until the fix was done. On others, the option was there; but the fix below had to be done in order for the ActiveX control to be successfully registered.

Fixing: I tried various combinations, repairing Adobe, reboots in between, etc. These steps, in this specific order, fixed the problem in the shortest amount of time.

1. Close all open applications
2. Launch Add or Remove Programs, Adobe Acrobat 8.1.1 Professional, Change, Next, Modify. Under the choices presented, select +Create Adobe PDF, + Acrobat PDFMaker. For the feature "Microsoft Internet Explorer", modify the selection from "This will be installed on local hard drive." to "This feature will not be available". Next, Update. Click Finish when done.
3. Right-click on the computer desktop, properties. Settings tab. Change "Color Quality" from "Highest (32 bit)" to "Medium (16 bit)". Click OK. Confirm you can still see the display by clicking Yes at the prompt.
4. Add or Remove Programs, Adobe Acrobat 8.1.1 Professional, Change, Next, Modify. Under the choices presented, select +Create Adobe PDF, + Acrobat PDFMaker. For the feature "Microsoft Internet Explorer", modify the selection from "This feature will not be available." To "This will be installed on local hard drive." Next, Update. Click Finish when done.
5. Launch Internet Explorer and confirm you can right-click "Convert to Adobe PDF".
6. If it does not work at first (it’s about 50/50 success while I was testing this fix), go to Tools, Internet Options, Programs Tab, Manage Addons… Highlight "Adobe PDF Content Menu Helper". At the bottom, "Disable" this addon; confirm, OK, OK. Exit Internet Explorer. Go back into IE, the same location, and "Enable" this addon; Ok. Ok. Test again (should work now).
7. Optional: Now that it’s working, you can go back and change Color Quality back to ‘Highest (32 bit)’. In my testing, that did work; but I noticed online for others which had to use the 16-bit to fix the issue; if they went back to 32-bit, after some undeterminite time the right-click Convert to Adobe PDF stopped working, and they had to run through the fix again. I suspect if this control has to be re-registered, when you are running at 32-bit Color Quality the re-registration fails. You may want to ask the person if they notice any different in color / video from 32bit to 16bit. You may decide to leave the setting at 16bit to avoid possible future problems.

Ok, now for the minor rant… I’m by no stretch of the imagination a programmer, so perhaps some activex / IE plugin programmer out there can tell me… why would my Color Quality set at 32bit prevent a plugin from registering?  I’m sure there’s a sound, valid technical reason—but I just don’t get it.

By the way.. yes, I know Adobe Acrobat 8.1.2 update was released a few weeks ago.  I haven’t tested it to see if it fixes this specific issue yet.

Finding computers with 'AutoAdminLogon' configured

Below is a mof edit and a suggested report to assist in finding computers which are configured to login automatically.  By design, your imaging process may leverage AutoAdminLogon.  In that case, AutoLogonCount will have a value--I would guess generally 2 or 3 would be your highest count reported.  If AutoLogonCount is in the hundreds or thousands or AutoLogonCount is blank that may point you to a security risk in your environment.

//`'`*._.*`'`*-
//  Reporting Class - for ConfigMgr, put this section in sms_def.mof
//`'`*._.*`'`*-
 
 #pragma namespace("\\\\.\\root\\cimv2\\SMS")
 
 [SMS_Report(TRUE), SMS_Group_Name("AutoAdminLogon"),SMS_Class_ID("SMSExpert|AutoAdminLogon|1.0")]
 class AutoAdminLogon : SMS_Class_Template
{
 [SMS_Report(TRUE),key] string KeyName;
 [SMS_Report(TRUE)]     string DefaultDomainName;
 [SMS_Report(TRUE)] string DefaultUserName;
 [SMS_Report(TRUE)] string DefaultPassword;
 [SMS_Report(TRUE)] string AutoAdminLogon;
 [SMS_Report(TRUE)]     uint32 AutoLogonCount;
};

//`'`*._.*`'`*-
//  Data Class - for ConfigMgr, put this section in configuration.mof
//`'`*._.*`'`*-

#pragma namespace("\\\\.\\root\\cimv2")
 [DYNPROPS]
 class AutoAdminLogon
{
 [key] string  Keyname="";
       string  DefaultDomainName;
       string  DefaultUserName;
       string  DefaultPassword;
       string  AutoAdminLogon;
       uint32  AutoLogonCount;
};

[DYNPROPS]
instance of AutoAdminLogon
{
KeyName = "AutoAdminLogon";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon|DefaultDomainName"),
Dynamic,Provider("RegPropProv")] DefaultDomainName;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon|DefaultUserName"),
Dynamic,Provider("RegPropProv")] DefaultUserName;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon|DefaultPassword"),
Dynamic,Provider("RegPropProv")] DefaultPassword;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon|AutoAdminLogon"),
Dynamic,Provider("RegPropProv")] AutoAdminLogon;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon|AutoLogonCount"),
Dynamic,Provider("RegPropProv")] AutoLogonCount;
};

A report to get you started: 

select sys.name0, aal.AutoAdminLogon0 [Auto Logon Enabled], aal.AutoLogonCount0 [Number of Auto Logons Remaining (BDD/MD)], aal.DefaultDomainName0 [Domain Name], aal.DefaultPassword0 [Default Password], aal.DefaultUserName0 [Default UserName]
from v_gs_AutoAdminLogon0 aal join v_r_system sys on sys.resourceid=aal.resourceid
where aal.AutoAdminLogon0 = 1

Outlook Cached Mode via Hardware Inventory

We're in the midst of a project to get all users into Outlook Cached mode.  We're using two methods to confirm this process, one is to look for a specific Group Policy being applied successfully (http://www.myitforum.com/articles/8/view.asp?id=11254) and checking the value of HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\UserNameHere\13dbb0c8aa05101a9bb000aa002fc45a\00036601, which, according to http://www.howto-outlook.com/howto/cachedmoderegkey.htm, contains information about cached or not cached.

Attached are 2 files, one is a vbscript you would run on a recurring basis, only when a user is logged in, with user rights, to read the contents of that registry key for the user and transfer the information to the HKLM part of the registry which SMS Hardware Inventory can pick up.  The other file is the mof edit you would add to sms_def.mof and/or mini.mof/configuration.mof (depending upon your version of SMS/ConfigMgr and whether or not you use a mini)

A couple of caveats to be aware of.  In the howto-outlook.com article, they mention that the enabled value is  84 01 00 00.  That is the HEX value of the registry key.  SMS reports on the Decimal value of the registry key, so in Resource Explorer you will see 132,1,0,0    If you happen to come across some great article explaining all of the possible values for this key, and what they mean, please remember to change hex to dec values (Run Calculator, view Scientific, if you've never done hex to dec conversions before).

Caveat #2:  Although in my environment the majority of computers reporting back show either 132,1,0,0 (Cached mode on) or 4,0,0,0 (not cached), there are a total of 19 different values reported back.  Read the howto-outlook.com article for the reasons why.

Other notes: the script pulls back 4 pieces of information:  The value of the registry key, the name of the default Outlook Profile from which that value was taken, the currently logged in username, and the time the script ran to gather that information.

PS: If you DO happen to know what all of the values of that key mean, please share!

Configuring SystemCenterTools.com's Enhanced User Discovery 1.1

Last summer, I had to rebuild our central primary site after hardware failure.  At the time, I took detailed notes of how I setup http://www.systemcentertools.com 's EUD, or Enhanced User Discovery 1.1, for SMS 2003.  I recently came across my notes and thought "This would be a good blog entry." 

After installation on your primary site server, you need to edit 1 file to configure.  There is another file to edit if you wish to pull in more AD Attributes than those in the default settings file.

File #1:   \program files\Enhanced AD user Discovery v1.1\Enhanced AD User Discovery.exe.config
Line 6:  change value="SMSDomain" to be your (shortname) domain.  I assume it might be something like   MYCOMPANY  (not mycompany.com)
Line 11: change value="" to be your fqn domain name.  Like   mycompany.com
Line 15: change value="SMSSERVER"  to be the name of your smsserver.
Line 19: change value="RC2" to be the site code of your smsserver.
Line 22: change value="c:\sms\inboxes\ddm.box\" to be the correct location for that folder on that sms server.  For me, we install sms to the E: drive, so I had to change it.
Line 27: (optional) change value="c:\enhancedaduserdisc.log" to   <yourdriveletter>:\sms\logs\enhaduserdisc.log.
 
(I called that optional simply because I like all my sms logs in the sms\logs folder, not on the root of c:
 
File #2 \program files\Enhanced AD user Discovery v1.1\aduserattribs.xml.  This next file you can leave alone forever; but if you want to pull in more ad attributes, you'd add them to aduserattribs.xml.  For me, I added 2 additional attributes.  I wouldn't mess with that file until you've confirmed success for the defaults attributes.

  <ADAttrib>
  <ADAttribName>telephoneNumber</ADAttribName>
  <DDRPropertyName>Telephone</DDRPropertyName>
  <DDRPropertyLength>128</DDRPropertyLength>
 </ADAttrib>
  <ADAttrib>
  <ADAttribName>ipPhone</ADAttribName>
  <DDRPropertyName>IPPhone</DDRPropertyName>
  <DDRPropertyLength>64</DDRPropertyLength>
 </ADAttrib>
 
The reason I added them was because at my company we have a VOIP phone system, and I wanted that attribute available for SMS reports for the helpdesk and techs.

How to test:
 
Double-click the executable (assuming your logged-in account has the credentials to read user objects in AD)
Open up the log file (for me, that was e:\sms\logs\enhaduserdisc.log) using trace32.exe
You'll either see if fail almost immediately if a configuration is incorrect; or, you'll see it start enumerating all of your user accounts out of AD.  For me, it only takes ~3 minutes to finish gathering data.  Then it has to send the DDRs into the ddm.box folder, and your SMS server has to pull in the information.  Depending upon your server, and the number of user objects in AD for you, I can't estimate how long that might take; but give it at least 5-10 minutes.  Then in the SMS console, the All Users collection, pick a user (like yourself) that will most likely have entries for email, department, title, description, first name, last name (which are the default attributes pulled in); right-click that user, and scroll through the list of things--you should hopefully see the new attributes (with data) listed!

How to automate so it pulls in any new or changed user information:
I set up a scheduled task on my primary site server to run that executable at 3 a.m. daily, using a service account.  On whatever schedule you normally use when checking on overall SMS Health, check the enhaduserdisc.log to confirm it is working as expected.

Notes: at this time, EUD 1.1 is not needed if you are running ConfigMgr 07; you can pull in additional Active Directory user attributes by modifying the existing Discovery Method for "Active Directory User Discovery", the Active Directory Attributes tab.