I'm having a scenario where a (very old) intranet is having issues opening office from within Internet Explorer using VBScript.
The scenario:
User clicks on hyperlink
is redirected to the following asp page:
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=9" />
<SCRIPT LANGUAGE=VBScript>
Set objOutlook = CreateObject("Outlook.Application")
Set myItem = objOutlook.CreateItemFromTemplate("<%=template%>")
myItem.Display
myItem.To = "<%=EmailTo%>"
myItem.Display
window.close()
</SCRIPT>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
</head>
<body bgcolor="#1d4392" >
</body>
</html>
Outlook boots, loads the template from disk
the end user makes edits and sends the e-mail
Unfortunately, the end users are greeted with the following error:
VBScript: ActiveX component can't create object: 'outlook.application'
Some info:
IE11
Office 365 64bit
Win 10 laptops
The page stopped working since the users migrated to laptops instead of using an RDS-based environment
The page runs flawlessly on my local machine (which isn't domain joined, as I'm a consultant, also Win10, O365)
In Event Viewer, I can see Outlook booting up, So I'm quite sure this isn't an IE Security config issue, the page runs under local intranet mode, where VBScript is explisitly allowed through GPO
I tested Word as well, same issue
Things I tried:
reinstalling office
repairing office
The "can't create object" is, in most of the case, caused by either :
the component not being installed
the component not being registered in the Registry (or is registered in 32 bit but not in 64 bit registry, or conversely)
a permission problem. Make sure that the Windows user account that is used to run you IIS App Pool have read + execute permissions over the folder containing the component DLL, and its dependant DLL's. You can troubleshoot the execution chain by using Process Monitor : https://www.howtogeek.com/school/sysinternals-pro/lesson4/
Can be downloaded from https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Related
I have two Yammer feeds that I need to embed in SharePoint 2010 using CEWPs. Each is on a separate page. The web part is linking to a text file in the Style Library. One of them is working correctly and displaying the feed. However, the other is opening the feed in the web part, but also pops up two windows with the other feed.
Both are embedded using the same script with the correct parameters. The only difference in the two being the "FeedId". Below is the contents of the text files (with the "Network" and "FeedId" parameters changed for privacy).
<div id="embedded-feed" style="height:800px;width:400px;"></div>
<script type="text/javascript" src="https://s0-azure.assets-
yammer.com/assets/platform_embed.js"></script>
<script type="text/javascript">
yam.connect.embedFeed({
container: "#embedded-feed",
network: "myNet.com",
feedType: "group",
feedId: "1234567"
});
</script>
Why would one of these cause popups with a different feed and the other work as expected?
This is not really a programming question and therefore may be deleted from this site. You are best to test the same Embed snippets with the configuration tool and see if you have the same issues. If you do, open a support request from within the O365 Tenant Admin portal so that someone can investigate the issue specific to your environment.
You should also note that SharePoint 2010 uses unsupported Document Modes forcing Internet Explorer to run with a down-level engine. As a result, you can experience many issues.
I'm having an annoying problem with OneNote (online) caching my Add-In. I'm sideloading my add-in and despite pushing a new build to my server, and doing a full refresh of the OneNote web page and re-inserting my Add-In, I still see the old add-in content. If I open a new tab using the Add-In URL found in my Add-In manifest, then I do see the new content so I'm almost certain it's a caching problem. In other words, I see the old content in the Add-In IFRAME provided by OneNote, but I see the new content if I load the same web page into a completely new tab.
Is there a setting or something I can do to defeat Add-In caching while I'm developing my Add-In?
NOTE: While we wait for a better answer, for now I am using the old trick of changing the Add-In URL in the manifest by adding a benign URL argument to the end of the URL that I increment with each version change. Hopefully someone will provide a better solution than this since it's a bit of a pain, but at least it's something for now.
It's not really OneNote Online that is caching your add-in - it's your browser.
Use the following HTML headers to prevent caching:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate"/>
<meta http-equiv="Pragma" content="no-cache"/>
<meta http-equiv="Expires" content="0"/>
Prevent caching of HTML page
In order to prevent caching of your JS, you might have to do more. I suggest appending a random number to your JS reference, as suggested here.
<script language="JavaScript">
var s=document.getElementsByTagName('script')[0];
var sc=document.createElement('script');
sc.type='text/javascript';
sc.async=true;
sc.src='http://PATHTOYOURSCRIPT.js?v' + Math.random();
s.parentNode.insertBefore(sc,s);
</script>
Preventing Cache on JavaScript files
I first created an MVC3 Intranet web application in Visual Studio 2010 Professional.
It worked just fine.
I then right-clicked on the application and chose "Use IIS Express..."
I also edited the application properties and disabled Anonymous Authentication but enabled Windows Authentication.
Nothing more. This is a bare-bones, default skeleton of an application that I want to start from.
Now when I run, I first get a pop-up window to login with my username and password. This is just as I expect. However, when I log in, the "Home" and "About" pages are not formatted correctly. It looks like IIS Express isn't reading my Site.css file.
How do I fix this?
Thanks,
- Paul
The default links for the style sheets typically use the ../../ directory navigation. When you're on a real webserver, those links typically fail 'cause now you're in a different folder setup. An easy way to correct them is to use:
<link href="<%: Url.Content("~/Content/style.css") %>"
rel="stylesheet" type="text/css" />
The url.content part will rebase the links to the current directory and will link up it's content correctly.
Hope this helps some, and good luck on your project.
I have a problem I haven't seen before. I am doing a realign on our company's website and am testing locally. However, when I upload to our test server I notice display discrepancies within the same browser (IE8)!
Here is a screenshot of the two pages, both viewed in IE8 but residing on different servers. In the page on the right, you can see there is a weird chunk of white space to the side underneath the .swf file.
Can anyone give any insight as to why the same page on distinct servers would look different in the same browser? I have also noticed a couple of other cross-server bugs within Firefox.
Thanks!
One possibility that comes to mind is IE8's compatibility mode. There is the X-UA-Compatible header directive that forces IE8 into compatibility mode or out of it. Maybe one of the servers sends out that information.
Try adding a compatibility mode directive to the header and see whether it has any effect:
<!-- Mimic Internet Explorer 7 -->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
and alternatively:
<meta http-equiv="X-UA-Compatible" content="IE=100" > <!-- IE8 mode -->
Reference at MSDN: Defining Document Compatibility
I've created a couple of Office plugins. The plugin shows a set of html files installed on the clients computer. The plugin uses a COM-accessible assembly which shows a WinForm with a WebBrowser on it. The plugin makes the WebBrowser navigate to a file on the clients computer. The assembly is also used in other programs to show the same information.
When showing the local html files using a 'normal' browser (e.g. double clicking a file in Windows Explorer) the browser popup a security warning about running active content. This is because we have some javascript in it. This warning is supressed by setting the 'Allow active content to run in files on My Computer' in the Internet Explorer settings. This solves the issue using a 'normal' browser.
Funny enough the 'active content' warning is not shown when getting the same file using a Word/Excel/PowerPoint plugin. It calls the same assembly, using the same WinForm and using the same content. Despite the setting 'Allow active content to run from My Computer' being false, the content is shown without a warning and the javascript is executed.
Now, the problem and the real question is that Outlook does the reverse. No matter what I use for 'Allow active content to run from My Computer' the browser warning about the active content in the html file is shown. When I confirm the message and allow the scripts to continue, the javascript runs fine. So, even when I set the 'Allow active content to run from My Computer' to true, the warning is given.
I've gone through all (sort of) relevant settings in Outlook, but nothing helps.
I assume that Outlook is using some kind of private context for a webbrowser (probably because it is using a webbrowser object internally).
The real question is: how can I make the Outlook plugin respect the IE settings?
(I understand this is a long story and maybe not clear enough. Please let me know if I have to elaborate more).
I couldn't get rid of the security warning without lowering the security setting. And that is not an option: we are talking about a project that will be installed on millions of computers.
I decided to go another route. Let's see if we can make the browser trust the html pages. So, what to do to get rid of the 'Active content' warning.
First I investigated what exactly triggers the warning. That was easy: any tag in your html file will do. And I need script, so removing that isn't an option. But, when hosted from a website, the scripts run fine and don't suffer from a warning. So, I investigated if it is possible to run my files in the Internet-context.
I found out there is a way, at least for IE (which in my case is sufficient). If you save a webpage as a complete HTML file from IE, the browser adds a comment to the html to signal its origin. Something like: . If you later open that stored html file, the file is shown in the Internet context.
So, I tried adding to the html file. And, voila, the file is opened in the Internet context. The security warning about active content is gone and the scripts are executed fine.
But, that raised another problem. We have a couple of window.open statements in the scripts and using that causes he cross domain browsing problems that in recent IE versions are blocked. Even if you use a relative path in the window.open call, if fails and you end up with a blank window.
In our case, we can (probably) decide to get rid of the window.open calls. But, if a reader ever finds a solution for using window.open in this scenario, I would be very happy if you let me know.
So, for now: case closed...
Internet explorer use Mark of web in such cases
<!-- saved from url=(0014)about:internet -->
<!doctype html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<title>A Mark of the Web Example.</title>
</head>
<body>
<p>Hello, World</p>
</body>
</html>
More info from here
https://msdn.microsoft.com/en-us/library/ms537628(v=vs.85).aspx