none
Excel 2007, Publisher Cannot Be Verified RRS feed

  • Question

  • I have a rather random problem.

    I have several Excel 2007 Document Level Customizations.  Below are some basics on these Office Business App's.

    • Each is built with Visual Studio 2008
    • Each is using VSTO 3.0
    • Built using the Excel Template Document Level Visual Studio Template.
    • These use a mix of .Net 2.0 and .Net 3.5 references.
    • Each is install from their own individual MSI.
    • Each MSI runs a custom action to add an Inclusion for their own installed customization.
    • Each Soloution has been signed, within Visual Studio, with a VeriSign Code Signing Certificate.
    • Each MSI has been signed by the same VeriSign Code Signing Certificate.
    • Each MSI loads the VeriSign Cert into the Trusted Publisher folder on Installation.

    The Problem: On a very few machines, I'm getting the Microsoft Office Customization Installer dialog stating "Publisher cannot be verified" and the Publisher on that dialog shows as "Unknown".

    9 out of 10 machines work fine and do not get the warning mentioned above.  These are a mix of Windows 7 and Windows XP Machines.

    The Machines with the problem all, so far, have been Windows XP.  Digging through these machines I find the following:

    Machines with issues have the following findings:

    • Each Installation shows that the Code Signing Cert is loaded in the Trusted Publisher Store.
    • Excel shows the Cert in it's Trusted Publisher list within the Trust Center.
    • The installation path is not included in the list of Trusted Locations (this is true on the working machines as well).
    • The default installation path is to C:\Program Files (or C:\Program Files (x86)).
    • Internet Explorer 7 was installed. (uninstalled the office application, upgraded to IE 8, still didn't help.  Thought Restricted Sites may not be accessible)
    • No "Restricted" sites are listed within Internet Explorer.
    • The registry entries on working machines and non-working machines do not have the following path to alter the Trust Prompting.  \HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\.NETFramework\Security\TrustManager.  The path ends at .Netframework, there is no Security or TrustManager sub folder/key.  Refers to article:  http://msdn.microsoft.com/en-us/library/ee308453.aspx
    • Excel Trust Center - Trusted Locations - has "Allow Trusted Locations on my network...)" unchecked
    • Excel Trust Center - Trusted Locations - "Disable all Trusted Locations..." unchecked.
    • Excel Trust Center Add-In's - "Require Application Add-in's to be signed by Trusted Publisher" has been both checked and unchecked and it has no impact on this warning message.
    • Excel Trust Center Add-in's - "Disable notifications for unsigned add-ins" is unchecked
    • Excel Trust Center Add-in's - "Disable all Application Add-in's" is unchecked.
    • Excel Trust Center ActiveX Settings - "For ActiveX Controls in documents not in a trusted location:", option selected is "Prompt me before enabling all controls with minimal restrictions".
    • Excel Trust Center ActiveX Settings - "Safe Mode" is checked.
    • Excel Trust Center Macro Settings - "For macros in documents not in a trusted location", option "Disable all macros with notification" is checked.
    • Excel Trust Center Macro Settings - "Trust access to the VBA project object model" unchecked and checked make no difference.  Tried both.
    • Excel Trust Center Message Bar - "Show the mesage bar in all applications..." is selected.
    • Excel Trust Center External Content - "Prompt user about Data Connections" selected
    • Excel Trust Center External Content - "Prompt user on automatic updates for Workbook links" is selected.
    • Excel Privacy Options, didn't mess with these, didn't see them as relevent to this issue.

    I'm at a loss at this point.  I know I've tried several other things but I can't remember them all at this point.  I'm really stuck with a very large customer on this issue and could use some pointers.  Any help would be GREATLY appriciated.


    Rob

    Saturday, February 18, 2012 12:50 AM

Answers

  • ANSWER FOUND!  What a struggle this has been...

    I contacted the Paid Support, however I ended up solving the problem on my own.  See below.

    Here’s the problem:

    As typical Office Customization development goes, we create a Project and Visual Studio automatically assigns (or we have to generate via Visual Studio) a Cert in order to get our Manifest files to build.  The VSTO and .Manifest files. 

    Inside the .VSTO and .Manifest file, there is an <RSAKEYValue> element that we need to copy and place in our Custom Action to load the customization into the client machines Inclusion list.

    When we finally got around to applying a valid CERT from VeriSign to our solutions, I had no idea that the RSAKEYValue would change.  So I never updated our CustomAction project with the new RSAKEYValue.

    The strange thing is that out of at least 15 machines these installers were tested on, including on one of Microsofts Support Tech's machines, there was no Trust popup message.  Everything looked great.

    On one machine, this machine I’ve been having problems with, we did get the Trust Prompt.

    I updated the RSAKeyValue in our CustomAction Installer Project to the new RSAKEYValue.  Did this for all of our Excel Document Level Customization solutions.

    Tested the new MSI installers on the problematic machine, and they fired up without a prompt.  Perfect. 

    Now i just wish I knew why on one machine this was a problem, but no problem on all other machines.


    Rob


    • Edited by Rob K In Dev Thursday, February 23, 2012 9:16 PM grammar
    • Proposed as answer by cjatmsModerator Friday, February 24, 2012 4:02 PM
    • Marked as answer by Rob K In Dev Wednesday, February 29, 2012 10:47 PM
    Thursday, February 23, 2012 8:10 PM

All replies

  • And just to be clear, when I say working machines, I don't get a prompt at all.  They simply fire right up and work without a problem.

    Some other Facts:

    • Customers Excel version is Excel 2007(12.0.6654.5003) SP2
    • Windows XP SP 3.

    Another trouble shooting step.

    • Download and ran the "Update Root Certifications 2011 (November)".  Did not help.


    • Edited by Rob K In Dev Saturday, February 18, 2012 12:55 AM
    Saturday, February 18, 2012 12:51 AM
  • Hi Rob,

    Thanks for posting in the MSDN Forum.

    It's based on my experience that your issue is a more complex issue of VSTO solution's deployment. I will invovle some experts into this issue to provide your better support. There might be some time delay. Appreciate your patience.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Monday, February 20, 2012 5:27 AM
    Moderator
  • Hi Rob,

    You have already done most of the things recommended in a
    host of content where others have reported the same problem so the list of
    applicable content below may repeat what you already reviewed. Please excuse
    any duplication resulting from pointing at the same target from different
    directions.

    See the responses by Mary Lee in this Forum thread:
    How do you create an MSI to deploy a VSTO 3.0 Add-in
    http://social.msdn.microsoft.com/forums/en-US/vsto/thread/514d6278-d7df-47c1-9e11-08a5a4c43ca4

    Deploying aVisual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft
    Office System Using Windows Installer (Part 1 of 2)
    http://msdn.microsoft.com/en-us/library/cc563937.aspx

    Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows
    Installer (Part 2 of 2)
    http://msdn.microsoft.com/en-us/library/cc616991.aspx


    Other content that may be informative to you in resolving the issue include:

    For Office 2010, there are some changes for security model. Please check this blog
    of Mary Lee:
    http://blogs.msdn.com/b/vsto/archive/2010/03/10/changes-in-the-security-model-for-office-solutions.aspx.

    For this scenario, you could change the installation path to the Program Files
    directory. The default setting is for Program Files path. The DefaultLocation
    value is [ProgramFilesFolder][Manufacturer]\[ProductName]. For this property,
    you could check this MSDN page:
    http://msdn.microsoft.com/en-us/library/cc563937(office.12).aspx.

    Another Forum issue about the same issue i.e.
    publisher could not be verified
    http://social.msdn.microsoft.com/forums/en-US/vbgeneral/thread/15c12a31-5511-4854-af24-dc0820948cbd

    Verifying publisher in Office 2010
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/bd53137f-19df-4877-b583-604b4d94af16

    Deploying Solutions for the 2007 Office System with ClickOnce using Visual Studio 2008
    Professional
    http://msdn.microsoft.com/en-us/library/bb821233.aspx

    Question:
    Have you tested the effect of changing a system from Windows XP to Windows 7?
    That does beg the question – are any of the problem systems under your control?

    In view of the meticulous job you have done in troubleshooting the issue, if nothing in
    the contents cited about your issue helps you resolve it, the issue requires a
    more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    If you do resolve the issue without using a
    support incident please let us know what you have done so other Forum users
    will share your process..

    Regards,
    Chris Jensen
    Senior Technical Support Lead

    Monday, February 20, 2012 8:05 PM
    Moderator
  • So here's something I could use help with.  I'm having a hard time finding how to verify some of the following.

    In the link provided by your response:

    Deploying Solutions for the 2007 Office System with ClickOnce using Visual Studio 2008
    Professional
    http://msdn.microsoft.com/en-us/library/bb821233.aspx

    There is the "ClickOnce and Visual Studio Tools for Office Runtime security Checks" section.  In this section, I follow along with the questions in which the Security Check process undergoes.  I can't answer point #2.  Whether or not the manifest requests "FullTrust" permission.  Can you help me identify how to check this?  I assume that it's a setting in the trustInfo section of the *.manifest file.  Below is the trustInfo configuration of our Manifest.  If this isn't the correct place to look, can you point me to the right place?

      <trustInfo>
        <security>
          <applicationRequestMinimum>
            <PermissionSet Unrestricted="true" ID="Custom" SameSite="site" />
            <defaultAssemblyRequest permissionSetReference="Custom" />
          </applicationRequestMinimum>
          <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
            <!--
              UAC Manifest Options
              If you want to change the Windows User Account Control level replace the
              requestedExecutionLevel node with one of the following.

            <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
            <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
            <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

             If you want to utilize File and Registry Virtualization for backward
             compatibility then delete the requestedExecutionLevel node.
        -->
            <requestedExecutionLevel level="asInvoker" uiAccess="false" />
          </requestedPrivileges>
        </security>
      </trustInfo>

    Based on this check list, bullet point # 5 is failing. What I can't understand is what would cause Excel/Office/VSTO to not be able to see whether or not the Certificate is Trusted? Basically, the solution acts like it can't access the "Trusted Publisher" store. Do you know of anything that would prevent a users execution of a VSTO Solution to have no access to the Trusted Publisher store?


    Rob

    Tuesday, February 21, 2012 7:01 PM
  • I think i still needed to address some of your questions, so here goes.

    Regarding...

    "See the responses by Mary Lee in this Forum thread:
    How do you create an MSI to deploy a VSTO 3.0 Add-in"

    I think I've been down this road heavily from a Document Level customization perspective.  Wasn't really able to find much extra help here.  Though perhaps it would help to note some of what our solutions are doing in relation to the post by Mary Lee.

    • We do have a CustomAction that adds the Document Level Customization to the inclusions list.  (solution ID and RSAKey is used)
    • We install the solution to a xxx\InstallDirectory\bin folder.  We then copy the *.xltx file to the xxx\InstallDirectory\ folder, overwriting a pretty much empty excel file that really is just a place holder for the file name.  We have a place holder file in the xxx\InstallDirectory\ folder so that we can add a Start Menu short cut to the Visual Studio Setup Project.
    • When we copy the *.xltx file from the xxx\InstallDirectory\bin folder to the xxx\InstallDirectory\ folder, overwriting the place holder, we execute the AddCustomization method in the Custom Action to properly set the _Assembly and _AssemblyLocation properties in Excel.
    • Our CustomAction also installs the Code Signing Cert from Verisign to the Trusted Publisher store.  Which works very well for 9 out of 10 installs.
    • So from a Trusted Solution perspective, we're being trusted from the Inclusion List and from the Trusted Publisher store. 
    • QUESTION:  I can't tell if the user has the My Computer zone as a Trusted Location.  I also can't find out how to determine this.  If you could help provide guidiance on the subject,  I would be appriciated.  Note I've seen some of the Excel Security Workflow diagrams state that the My Computer zone is by default a "Trusted Location".  But I'd like to verify that this client PC has My Computer as a Trusted Location.  I need some help doing this.

    Regarding ...

    "Deploying aVisual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft
    Office System Using Windows Installer (Part 1 of 2)"

    Also Regarding ...

    Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows
    Installer (Part 2 of 2)

    • Our installers were built based on this documentation.  As far as I can tell, we're adhereing to all guidelines.  With the added improvement of installing to a xxx\InstallDir\Bin folder.  Which allowed us to use the Visual Studio Setup Template project and create short cuts to a copy of the Document Level Add-In without having to alter the installed Excel Template.

    Regarding ...

    "Other content that may be informative to you in resolving the issue include:

    For Office 2010, there are some changes for security model. Please check this blog
    of Mary Lee:
    http://blogs.msdn.com/b/vsto/archive/2010/03/10/changes-in-the-security-model-for-office-solutions.aspx."

    • The link you provided isn't working.  It's got a trailing period.  Other developers trying to review this link, drop the trailing period.
    • Regarding the article provided by this link, we're using Option #1.  Which works on most machines.

    Regarding ...

    "For this scenario, you could change the installation path to the Program Files
    directory. The default setting is for Program Files path. The DefaultLocation
    value is [ProgramFilesFolder][Manufacturer]\[ProductName]. For this property,
    you could check this MSDN page:
    http://msdn.microsoft.com/en-us/library/cc563937(office.12).aspx."

    • That is where we currently install.  That's are default install path as set in the default location of the Visual Studio Setup project.

    Regarding ...

    "Another Forum issue about the same issue i.e.
    publisher could not be verified
    http://social.msdn.microsoft.com/forums/en-US/vbgeneral/thread/15c12a31-5511-4854-af24-dc0820948cbd"

    • This article refers to a network install.  We're always installing to the C: drive as mentioned in the comment above regardign Default Install Paths.

    Regarding ...

    "Verifying publisher in Office 2010
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/bd53137f-19df-4877-b583-604b4d94af16"

    • this article is Add-In centric and really doesn't relate to a Document Level customization as Document Level customizations don't have the Add-In registry entry requirements.

    Regarding ...

    "Deploying Solutions for the 2007 Office System with ClickOnce using Visual Studio 2008
    Professional
    http://msdn.microsoft.com/en-us/library/bb821233.aspx"

    • We use a MSI deployment model, not a Click Once deployment model.  Though through signing, there are relationships between these deployment models, they do differ.  The contents of this article has not really helped identify the causes or solutions to this issue.

    Regarding ...

    "Question:
    Have you tested the effect of changing a system from Windows XP to Windows 7?
    That does beg the question – are any of the problem systems under your control?"

    • I'm not sure wehat you mean.  We have installed to both Windows XP and Windows 7.  So far, I haven't seen this as a problem on a Windows 7 machine.  I have seen this problem on Windows XP, using the exact same MSI.  However I've also seem some Windows XP machines (unfortunately including my own test machine) install the exact same MSI without a problem.  I do not want to upgrade the Windows XP machine to Windows 7 at this time.  I don't know if the process will wipe out the bug we're running into and leave me to have to trouble shoot it on an even more challenging client PC.  Right now, I'm dealing with a customers test environment and 1 machine in there test environment is having this problem.  Other Win 7 and Win XP machines in the test environment are not having this problem with the exact same MSI installer.  I'd like to identify the cause and solution to this issue prior to rolling out 18+ applications to the customers production environment.

    I'm in the process of getting an authorization to open a Microsoft Support incident, however if you can review the few questions, perhaps only 1 outstanding question, I would greatly appriciate it.


    Rob

    Tuesday, February 21, 2012 10:59 PM
  • Chris,

    I have to apologize on this a bit.  Per the customer, I've "misunderstood" their test environment.  The customer has had only one Windows XP machine to test on and that machine is the only one getting this Install / Don't Install "Publisher cannot be verified" prompt.  However on my own Windows XP machine, I don't get that prompt.  We do have this on several Windows 7 machines and haven't had a problem.

    That being said, do you know anything specific to Windows XP that may cause a Document Level Solution to fail in finding the Trusted Publisher certificate?

    Something to note is that there could be Group Policy settings causing a problem here and I've not found a handy list of group policy settings to review.  My personal Windows XP Test machine is only part of a Work Group.  Where as the customers Windows XP machine is on a domain.

    Thank you,


    Rob


    • Edited by Rob K In Dev Wednesday, February 22, 2012 12:41 AM
    Wednesday, February 22, 2012 12:40 AM
  • Hi Rob,

    Referring to your question about Group Policy, please see
    the first article below. Beyond that are links to other content that may be
    helpful.

    924617  How administrators can use Office policy templates together with the Group Policy
    settings of Windows
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;924617

    Further links to content re: Group Policy

    More general information about Windows XP is at
    http://technet.microsoft.com/en-us/library/bb491054.aspx

    For Windows XP  See “Service
    Pack 2 Feature Management Using Group Policy”
    http://technet.microsoft.com/en-us/library/bb878159.aspx

    And the following:
    890955  Some Group Policy settings may be
    displayed in Extra Registry Settings in the Group Policy Management console in
    Windows XP SP2
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;890955

    SOX041206700011    How to print group policy Settings in XP
    https://vkbexternal.partners.extranet.microsoft.com/VKBWebService/ViewContent.aspx?scid=SO;US;SOX041206700011

    SOX031002700001         XP specific Group Policy settings disappear

    https://vkbexternal.partners.extranet.microsoft.com/VKBWebService/ViewContent.aspx?scid=SO;US;SOX031002700001

    307900 Upgrading Windows 2000 Group Policy for Windows XP

    http://support.microsoft.com/?id=307900

    TechNet site for Group Policy discussion for Windows server :
    Windows Server Group Policy Home - Microsoft TechNet: Resources ...
    http://technet.microsoft.com/en-us/windowsserver/bb310732

    The first link is the most relevant to your situation. If nothing explains and helps you resolve your issue please consider referring to paid support with the Microsoft Customer Support resources who specialize in security.

    Regards,
    Chris Jensen
    Senior Technical Support Lead


    Chris Jensen

    Thursday, February 23, 2012 4:00 PM
    Moderator
  • Chris? 

    Regarding the first link, do you know if the Group Policy files for Excel 2007 and Office 2007 will read in and load existing Group Policy settings?  or does it just give you settings you can use and doesn't really display what's already set?

    And as an update to this issue, my customer has installed to a different Windows XP machine onsite without error.  So this is very machine specific, and pretty much driving me insane. 

    Rob


    Rob


    • Edited by Rob K In Dev Thursday, February 23, 2012 6:20 PM
    Thursday, February 23, 2012 6:18 PM
  • ANSWER FOUND!  What a struggle this has been...

    I contacted the Paid Support, however I ended up solving the problem on my own.  See below.

    Here’s the problem:

    As typical Office Customization development goes, we create a Project and Visual Studio automatically assigns (or we have to generate via Visual Studio) a Cert in order to get our Manifest files to build.  The VSTO and .Manifest files. 

    Inside the .VSTO and .Manifest file, there is an <RSAKEYValue> element that we need to copy and place in our Custom Action to load the customization into the client machines Inclusion list.

    When we finally got around to applying a valid CERT from VeriSign to our solutions, I had no idea that the RSAKEYValue would change.  So I never updated our CustomAction project with the new RSAKEYValue.

    The strange thing is that out of at least 15 machines these installers were tested on, including on one of Microsofts Support Tech's machines, there was no Trust popup message.  Everything looked great.

    On one machine, this machine I’ve been having problems with, we did get the Trust Prompt.

    I updated the RSAKeyValue in our CustomAction Installer Project to the new RSAKEYValue.  Did this for all of our Excel Document Level Customization solutions.

    Tested the new MSI installers on the problematic machine, and they fired up without a prompt.  Perfect. 

    Now i just wish I knew why on one machine this was a problem, but no problem on all other machines.


    Rob


    • Edited by Rob K In Dev Thursday, February 23, 2012 9:16 PM grammar
    • Proposed as answer by cjatmsModerator Friday, February 24, 2012 4:02 PM
    • Marked as answer by Rob K In Dev Wednesday, February 29, 2012 10:47 PM
    Thursday, February 23, 2012 8:10 PM
  • Hi Rob,

    Thank you for sharing your resolution with the Forum users.

    Regards,
    Chris Jensen
    Senior Technical Support Lead


    Chris Jensen

    Friday, February 24, 2012 4:02 PM
    Moderator