I recently upgraded to Windows 11. I'm fully updated and have the latest Office 365 updates as well. Unfortunately, I'm finding that my "DoCmd.SetWarnings True" VBA actions no longer work in all my legacy Access apps. The action still works fine on my Windows 10 and Server 2019 devices. Anyone else experiencing this (or other VBA issues?)
Thanks!
It appears that during the installation of Office 365 on my new Windows 11 laptop, the Action Queries check box in Options -> Client Settings is disabled by default. This affected all databases on my laptop. I enabled it and all works fine.
Related
I am using Intraweb version 14.0.0 on C++Builder 10.2 Tokyo.
I have constructed a test application using TIWServerController and TIWApplication.
When I run the application it shows the controls on the web browser, but I am not being able to get access to the same application using another web browser window of the same kind.
How can I use IntraWeb to serve the same application to several users from different locations of the same local network ?
Thank you very much.
Jayme Jeffman
I have found the problem. The version of IntraWeb (14.00) which was added to C++Builder 10.2 Tokyo community edition does not work the same way as it does on the paid version which has the 14.2.10 attached to the paid edition of C++Builder.
I have asked to a collegue of mine who has the paid edition to build the same test application I have made and everything is now working fine. Including the port number that now is always the same set in the IWServerController instead of start each time with a new one.
I have a VS2013 website developed in VB with Windows 10. I have tested it for years but now after migrating to Windows 10 when I go into debug mode, Edge pops up and asks for a user id and password. I have no user id or password that it accepts and I don't want that to happen anyway since it doesn't happen in production.
How can I get rid of the login requirement?
It sounds like your site has windows auth switched on. Ordinarily IE would negotiate for you and sign you in seamlessly. Edge doesn't seem to handle NTLM in the same way. To get your previous experience you could just switch the debug browser to IE11. This also has the benefit of enabling JS debugging which also currently breaks with Edge as VS2013. I'm sure these issues with Edge and VS will be fixed shortly.
Firstly, please don't reply with the generic advice not to automate Word on a server or a link to the MS web page on "how to automate word on a server if you really must". I am aware of this.
I have a process which runs as a Windows service and uses .Net OLE interop to automate Office (mostly just Open and SaveAs). This code has worked reliably for 8 years on literally hundreds of servers using many combinations of Windows and Office versions, both 32 and 64 bit, so I am happy that the mechanism is reliable. So far...
With Server 2012 R2, it works with PowerPoint and Excel but fails trying to open a word document:
System.Runtime.InteropServices.COMException (0x800A16A0):
The file appears to be corrupted.
at Microsoft.Office.Interop.Word.Documents.Open...
My observations so far which may or may not be relevant:
fails on all documents
works fine in Windows 8.1
the same problem has happened both on a customer site and in our test environment, so is unlikely to be purely environmental
my application is using .Net 3.5
the code is linked against the 2003 Interop assemblies (obviously later office versions are supported by assembly binding redirection)
we have tried it with office 2013 both 32 and 64 bit with the same results, but not tried earlier versions of office
it fails whether the service is running as LocalSystem or as a standard user account
if we run the service process in the foreground (i.e. literally double-clicking on the executable) the problem does not happen
Obviously I still have things to investigate but interested to hear if anyone else has seen this specific problem even if you haven't solved it. Please note there are many difficulties and problems with office automation so unless your symptoms are very similar to mine, you probably don't have the same problem.
Same issues here but got this fully resolved now.
I have a Word 2013 in combination with Windows 2012 R2 Server running in a service process which does everything I want without the need of a interactive session to be started. I use this to convert documents to PDF files. Inside the Windows service I host a WCF service.
Create folders: (replace System32 with Syswow64 depending of you use x86 or x64 bit edition)
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache
C:\Windows\System32\config\systemprofile\Desktop
Last and most important step!
Start - run - dcomcnfg.exe
Open properties -> Component Services - DCOM Config - Microsoft Word 97 - 2003 Document (Note that the version is not mentioned here but that does not matter Office 2013 will use this as DCOM config)
Open tab Identity. Configure the run as a the local Administrator account. I did some tests Word 2013 will work just fine even if no interactive session is started for the user.
We(My Company) are currently facing the same problem, it is pretty much a carbon copy of your problem. We have completed extensive testing around this area and I am now in talks with MS support engineer trying to find a work around.
Unfortunately this is something they don't want us doing, I think they have tightened security on the Windows Server 2012 to stop people from doing this.
What we have tried which should help you:
Server 2012 | Word 2007 | Failed
Server 2012 | Word 2010 | Failed
Server 2012 | Word 2013 | Failed
Client 8.1 | Word 2013 | Failed
Our problem stems from the fact we are running word with a user who isn't associated with the LOCAL system user(i.e. the type of user you have when you are logged into the machine) Windows will just not allow this to happen anymore.
Myself and the MS Engineer are working on "Fooling" windows into thinking it is running Word as a local service, however the MS Engineer said it was a long shot at best and so far everything we have tried has resulted in failure. It's not looking good.
Sorry I don't have an answer for you, but I suppose its good know you are not alone?
I had the same problem with MsOffice 2010 (32bits) and Windows Server 2012R2 (64bits). Word, Excel, Powerpoint don't work with localAdmin.
I created the folder C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache like Andy did and it now work perfectly !
Thanks Andy :)
My service use MS Word for data merging and concatenations functions.
I'm using Word 2016 on Windows Server 2012 R2 .
My log says that Word is opened but when the document is opened is throwed an error.
I've first created all the 4 folder suggested:
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache
C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache
C:\Windows\SysWOW64\config\systemprofile\Desktop
Only after creating the last directory the problem was solved.
I've not used DCOM config; my application use an user account with administration priviledges; there was no need to use LocalSystem account with "interaction with desktop" options.
Thank you.
We had a working solution for this for quite some time. However the solution broke when we tried to install it on a fully updated 2012 RTM R2 Server. On a 2016 Server we don't see this issue.
In order to make it work again on Windows 2012 R2 Server and also in a none interactive desktop environment:
Follow these steps!:
Actions to solve the issue on a Windows 2012 Sever R2 which is fully updated by Windows update:
Start - Run - mmc comexp.msc /32
Expand: Component Services – Computers – My Computer – DCOM Config
Search for: Microsoft Word 97 – 2003 Document
RMC – Properties – Go to tab: Identity
Set from “The launching user” to “This user”.
Use a “local Administrator account” which has once singed in to the server machine and has opened Word at least once in an interactive desktop.
Last step: REBOOT THE SERVER! And use a new document name to test your solution again.
Like known and said in the other answers these folder need to be created and accessible by the calling user (local system) normally or the user you configure in the prev steps.
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWow64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache C:\Windows\SysWow64\config\systemprofile\Desktop
Thanks for all the help OP and contributors. After creating the INetCache folder it worked out for me. I have done the following to get everything working without an active session(WS2012 R2 / MS Office 2013 64x):
Create a local admin user and log in to setup any printers(printing to file) as well as default word options.
Point the DCOM config identity to the local admin user created.
Create the following file :C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache
For some machines you need to run " mmc comexp.msc /32 " to set the DCOM setting for MS Word. I found that we needed to do this when 32 bit version of Word was installed only.
I've just been going nuts to sort this and have tried numerous solutions. I finally resolved this by changing the Identity to "This User". I then used the account that my app pool ran under and also had to add this user the "Administrators" group..
Phew... hope this helps someone too.
We have a problem with our SharePoint 2010 site that has SSRS 2008 R2 Integrated reports. When viewing the Actions menu, the Print option is missing.
This may seem like an easy answer... Put it in Compatibility Mode. This would work, HOWEVER, we have a custom .NET app that does NOT work with Compatibility mode turned on. I have no control over it, I just have to work around it...
So, I was able to resolve other IE 11 compatibility issues like InfoPath forms crashing out by adjusting the master page and making the compatibility mode set to 9 in a meta tag. I added the same meta tag to the RSViewerPage.aspx page with no luck.
Is there anyone out there that may have an idea on how to get around this issue? Many of our outside users have upgraded to Windows 8.1 and cannot go back to an earlier version of IE.
The issue is SQL Server R2 without SP2. I had to upgrade to Sql Server 2008 R2 SERVICE PACK 2.
The version of RsClientPrint you get with R2/SP2 is 10.50.4000, while
the version I had was 10.50.1600.
ReportViewer's Print Button Incompatible with IE 10?
I had some issues with our Sharepoint site and IE - even using Compatibility not always helping.
What I found out is something related to User Authentication not picking up.
To work around this - I was clicking on the Site logo to redo the process of authentication and that was always doing the trick.
Is this happening with all the site users?
I installed Microsoft SharePoint and Project PWA on Windows Server 2008 R2.
When I want to open Library in Windows Explorer, I randomly get an error:
Your client does not support opening this list with Windows Explorer
When I open IE it's working for 1st and 2nd time, but after some clicks it's not working anymore and I need to restart IE and then it normally works for couple of times.
When it not working through Sharepoint it also not works via \server\DavWWWRoot\PWA and oposite.
I'm searching through the web for weeks and didn't find any solution.
Do you have any idea what should be wrong here. Any suggestion is welcome :)
I had the same exact issue with Windows 7 and explorer view. The following steps resolved the issue for me:
First - be sure that the Web Client service is running (run>services.msc).
Next - In I.E. check Tools>Internet Options>Security>Local Intranet>Sites>Advanced and add the site that you want to use explorer view with.
This finally fixed it for me. I hope that you have already found a solution to this issue! I was surprised at how difficult it was to find a solution to this problem!
This error message is a symptom to a billion different problems.
I solved this problem when I realized my XP32 box could do this just fine with IE8. So I reverted to IE8 in 7x64 (you have to do it by uninstalling updates for IE until you're back at 8) and it didn't work. The build versions were different and on the 7x64 "about" box it said IE8 was using 256-bit cipher while in XP32 it had 128-bit. That to me was a hint that there may be 64-bit issues even when you run the 32-bit executable.
Then I found this hotfix so I reinstalled the windows update for IE10 and then installed this hotfix. Now I'm able to open the TeamCenter site in question in windows Explorer. IE10 reports it's version 10.0.9200.16686. I cannot guarantee that it was the hotfix alone (and not also the reinstallation of IE10) which fixed it. But I'm willing to bet it was the hotfix alone.
In XP I found it impossible to then map this network location to a drive letter, as mapping doesn't like URL's. However in Windows 7 you can transform the URL so that it is interpreted as a Windows share. If the URL of a given folder is of this form:
https://somesharepoint.com/folder1/folder2/folder3
you can also access it as
\\somesharepoint.com#SSL\DavWWWRoot\folder1\folder2\folder3
and, in this form, it can be mapped to a drive letter.
I do have issues at that point that even with IE10 open and logged in to the site I see some random time-out like problems and I get kicked off (and prompted to log in again in IE10). My situation is complicated because the site I'm accessing requires an Exostar token to log in, so I have to log in via website no matter what.
If it helps any one do the steps suggested above:
Make sure to use 32 bit internet explorer (program files (x86)/internet explorer).
Like was mentioned above Web client must be started.
You may also need to add your site to trusted sites in internet explorer.
Make sure enabled protected mode in internet options is disabled.
This is what finally fixed it for me: Check "Keep me signed in" on the login page. This was the key for me. Will not work without it checked in my case.
I had the same symptoms, and it turned out I don't have a root site collection. Creating one solved this for me.
Summarized the troubleshooting steps here:
http://letitknow.wordpress.com/2012/07/22/your-client-does-not-support-opening-this-list-with-windows-explorer-error/
There can be multiple reasons for it.
One could be using IE x64 version. It won't work there.
Secondly, check out this blog:
http://blogs.technet.com/b/asiasupp/archive/2011/06/13/error-message-quot-your-client-does-not-support-opening-this-list-with-windows-explorer-quot-when-you-try-to-quot-open-with-explorer-quot-on-a-sharepoint-document-library-in-office-365-site.aspx
I experienced the same problem as well.
And I found out that if none of the above options are working, and if you work in an organisation, maybe the proxy is blocking the "Open with Explorer" option.
I did the same, and removed the proxy and it worked just fine.
this fixed it for me ( however in windows server 2008 you may need to install desktop experience i think its called)
After you log into windows go into services then restart the WebClient then see if you can use explorer view without the error " your client does not support. blah blah blah" if it does work then. make a batch file that says:
net stop webclient
net start webclient
then make a scheduled tasks that runs that batch file at start up. Have it run as a user with administrative rights, make sure you tell it to run even if user is not logged in. it should prompt you for the password of the admin account you selected. this worked for me with windows 7.
I found online where the error can occur intermittently with SharePoint 2010, however I think the SharePoint version is irrelevant. They said the client polls for a SharePoint root site and that the error occurs if one isn't found.
We have not seen the error since I created a root site even though we’re only using WSS3. Our errors began when we changed clients to Windows 7. So in our case it sounds like the issue could be the root site polling due to an IE8 security change in Windows 7.
SOLUTION:
*you on x64 bit machine* so solution is that there is no problem but you are using the wrong IE shortcut.
There are different IE types you can use (just type Internet Explorer in start search bar) and you will see..
Internet Explorer (64-bit) - won't show any sharepoint add-ons
Internet Explorer (No Add-ons) - won't show any sharepoint add-ons
Internet Explorer - only this will show sharepoint add-ons and will
work so basically make sure you always use this version of IE