Background: One of my coworkers has a project that is written in VBA to use MS Access 2003 Run-time as a front-end for a MSSQL database. It's an internal project used by multiple users operating in terminal sessions on a Server 2008 R2 box.
Problem: Every time the Access project is opened, users are greeted with a Security Warning:
This file may not be safe if it contains code that was intended to harm your computer.
They have the option to Cancel or Open. The users would like to be able to skip this prompt.
Since the full version of Access is not installed, users cannot alter their individual security levels and the VBA project cannot be signed with selfcert.exe certificates. (I'm not sure that it would work for multiple users anyway?).
Ideal fix: I'm hoping there's GPO or registry key that alters security settings for Access Runtime, but am open to other suggestions. I'm sure the problem could be fixed by purchasing a license for the full version of Access and a certificate from an approved CA, but this project doesn't have any budget for it.
Update: Have confirmed that the guy who put this project together did it in Access 2003 and does not want to re-test for Access 2007/2010 runtimes. So we're stuck with 2003 Runtime.
Very late answer, but it might help someone. There is a way to do this. I created a shell for my Access apps (originally just to auto update my applications), and during this discovered you can completely workaround Access 2003 security (& 2007 etc with Remou's Trusted Locations).
Set the SecurityLevel in the registry, run the mdb via commandline, reset the registry.
Root: HKCU; Subkey: SOFTWARE\Microsoft\Office\11.0\Access\Security; ValueType: dword; ValueName: Level; ValueData: 1; Check: IsAccInstalled('11.0'); Flags: dontcreatekey
Level 1 = Low, No action; 2 = (Default) Medium, Prompt; 3 = High, Deny?
You can also run your mdb with COM, setting the SecurityLevel via COM before opening the mdb.
However COM wont work for runtime (and you cant identify the OS process later via a unique commandline as I needed to)
Answering this one just to say that no, there doesn't appear to be a way to avoid the security warning for Access 2003 Runtime without actually signing the project.
Related
im working on a Window server 2008, in this server i developed a vb.net 2008 console application that open a excel 2003 file and use its contents to create a xml file, so i have two situations:
1. Differences in execution of the program: if i run the application from the Visual Studio or directly from the executable it open and process the excel without problems but if i configured a task on the windows task scheduler or in the adtempus that execute this program its failed and throws this exception:
Exception from HRESULT: 0x800A03EC- at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad)
at .Module1.convertExcelToXmlFile(String excelFile)
i have read alot about this exception, but at the moment im unable to resolved, so I want to know how this program can execute correctly from Visual Studio or directly from the execute but failed when its execute on a task if both situations are in the same server? is there a way to fix this behavior?
2. In the console application when i open the excel file with the open method, the file in excel appears for a few seconds then it closed, is there a way to access the excel file contents but that the file dont show in Ms Excel?
thanks.
You should not be using Office Interop in an unattended process.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
http://support.microsoft.com/?id=257757
There are a number of products that will manipulate Excel docs and run correctly unattended.
Is the Excel file you're trying to open on the network?
If so, the problem is most likely because your Task Scheduler service and any jobs it runs are (by default) running under the local SYSTEM account, which is prohibited from network access.
If you change the task to run under a different account (say, for example, a domain account that you have given privileges for the remote fileshare). (Note that this change may effect how other scheduled tasks run, so you'll want to be quite sure of the permissions needed.)
Just in case you have not figured it out yet, the most-likely resolution which worked for me can be found at this URL :
https://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64?forum=innovateonoffice
If your server is a 64-bit one, create a folder named 'Desktop' in the below mentioned path i.e. C:\Windows\SysWOW64\config\systemprofile\Desktop
If your server is a 32-bit one, please make this folder C:\Windows\System32\config\systemprofile\Desktop
My application (vb.net windows application deployed via ClickOnce) uses Word to open and fill .dot templates to create new Word documents. I reference Microsoft Word 14 Object Library and uses this code :
Dim oWord As Word.Application = Nothing
Dim oDoc As Word.Document = Nothing
Try
oWord = New Word.Application
Dim strFileName As String = ""
Select Case strType
Case "LettreReception"
strFileName = Path.Combine(GetParam(1), "Template_LettreReception.dot")
If File.Exists(strFileName) Then
oDoc = oWord.Documents.Add(strFileName)
On the last line I receive "could not open macro storage" error on deployed machines (not on my development machine).
I develop with Windows 7 - Office 2010 - VS 2010 (.Net 3.5). My deployment machine is also a Windows 7 with Office 2010 installed.
I tried to remove normal.dotm (I found some links advicing it) without success. The .dot template used contains no macro.
Check the properties of the word document and make sure the files are unblocked. Sometimes when you get the documents from a different computer or download them from the internet they will be blocked which will cause the the throwing of this exception "could not open macro storage"
Because Word Interop is actually running behind the scenes as if it was running in an interactive session, certain permissions are required of the account used during execution.
Are you using Windows Authentication and impersonation in you web app? If so, the user being impersonated must have local log on rights to the server to run Word... In addition, you must actually log on to the server with that account at least once so that a profile exists on that machine for that user so the registry hive can be loaded. I've also found that you may need to actually run Word at least once as that user (to make sure any first-time initialization messages get taken care of before trying to run Word from code).
If not, then the service account that the application is running under (usually NETWORK SERVICE) requires the aforementioned permissions (which I will describe shortly) and you'll have to do something fancy like loading a registry hive dynamically at run-time. Personally, I prefer implementing an in-code temporary impersonation with a user account that has local log on permissions on the server in question.
Local log on permissions can be a bit tricky depending on your network and group policy configurations (if you want to be somewhat secure and not just use a Domain Admin account).
The reason everything works on your computer running in VS is because the context of the web application is YOUR user account - which, of course, has local log on permissions on your machine with a registry hive that can be loaded.
Now for the permissions:
First, you must run "dcomcnfg" on the server and make the following configuration change:
Right click on Component Services\computers\My Computer\DCOM Config\Microsoft Word 97 - 2003 Document and go to Properties
In the Properties screen, go to the Security tab and change the "Launch and Activation Permissions" to Customize.
Click the Edit button and add the local computer NETWORK SERVICE account (If not using impersonation... If using impersonation, add the appropriate user or group) to the list of users and check "Local Launch" and "Local Activation"
Make sure that the local computer NETWORK SERVICE account (If not using impersonation... If using impersonation, then the appropriate user or group) has appropriate read/modify permissions on the folder(s)and file(s) that you will be opening and/or saving to.
Create a "Desktop" directory under: C:\Windows\System32\config\systemprofile\ and give Full permissions to the local NETWORK SERVICE account (or the account that your ASP .NET application is running under) [NOTE: I believe this and the next step only apply if NOT using impersonation]
Give Modify/Read/Execute permissions on the C:\Windows\System32\config\systemprofile folder
Hope that helps some and wasn't too confusing...
Right click on the file that is opened -> Click the Unblock tick box -> Apply
Worked for me at least.
"could not open macro storage" is telling you that VBA is looking for a particular structured storage file such as a .DOT or .DOC, and looking for the storage (a kind of stream within the file) in that file that contains the VBA code. If it can't open it, possible reasons include:
the container (the .doc/.dot) isn't there
the container cannot be opened with the caller's permissions
the container is there but the storage isn't there (e.g. on the target system there is a container with the expected name, but it contains no macros)
the container is there and the storage is there but cannot be opened with the caller's permissions
So one thing to do is to look through your project looking for anything it references (perhaps even other objects or DLLs that you specified via Tools->References) that is not also being delivered with your template.
Go to the Word document (if it's a template, be sure to open it, not create a new document with it) and disable Protected View:
https://casecomplete.zendesk.com/hc/en-us/articles/200685047-Could-not-open-macro-storage
This might be wrong place to ask this question.
I spent effort in setting up thr sharepoint 2010 2 tier farm. I have settled up the sql server databases required for sharepoint, installed on different machine. and sharepoint on another machine. it took around 6 days, but at the end i noticed that i have computer name with something "win43453-676" like this. where as my manager wants to to keep relavant name like "CentralAdminMachine" of central admin pc. if i changed the name of machine , i am unable to open even central administration site. is there any remedy to change this name in configuration database and all....?
There is both a PowerShell cmdlet and an STSADM command that allow you to change the server name. Both require that you first change the name through the standard Windows System control panel. After that (and a restart) you can use:
Rename-SPServer [-Identity] <OriginalServerName> -Name <NewServerName>
http://technet.microsoft.com/en-us/library/cc263117(office.12).aspx
or
Rename-SPServer [-Identity] <SPServerPipeBind> -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
http://technet.microsoft.com/en-us/library/ff607556.aspx
There are some people who seem to recommend the STSADM (even though PowerShell is the Microsoft recommend way on SharePoint 2010) because it seems to work and not the give error that the PowerShell command does about feature dependency, but it looks like you can try either one.
And you may need to update your alternate access mappings to enable any custom URLs to work as well.
We're instantiating a VB6 COM component from classic ASP on a Windows 2000 Server using Server.CreateObject. We get the 'invalid progid' error message.
The DLL is registered. In fact we can run a VBS file that uses WSCRIPT to instantiate and run the component so that shows it is registered.
Why is ASP failing to instantiate it? Is this permissions related? We've tried things like putting the IUSR and IWAM accounts in the Administrators group (just temporarily) and it didn't seem to help. We've granted Everyone access to the folder containing the DLL.
We were able to register the DLL on another server and run the same ASP page there so it does work.
Just one other thing: the server may have been renamed at one time (the IUSR account name differs from the machine name).
Any help appreciated!
-Krip
You haven't said what OSs are involved, for example those supporting UAC. You also haven't said how this library was registered.
It is very likely that you tried to self-register this thing (for example running regsvr32.exe) and the registration ended up in a virtualized location. Thus it will only be seen as "registered" by a process running under the same user context and subject to virtualization (no manifest declaring it Vista aware).
It could also be registered "per user" in the user's HKCU, but this normally doesn't happen without taking special action.
Even a PDW package would get around this, but an Installer MSI would be better. Just copying things around and running regsvr32.exe on them is not proper deployment.
Start Procmon and see what registry key your app is trying to access. Then go to that key and see where it points.
I am thinking that you simply misspelled the name of the ProgID in your ASP.
My coworker is trying to register some COM components (which I wrote) via RegAsm.exe and it says he needs Administrator privileges. His account has admin privileges but he is not logged in as Administrator. Is there a way to use his regular user account and succeed at this task?
I work in an environment/jurisdiction where giving local admin access to all users is simply not possible (legal/compliance/regulations will not allow).
It appears there is no equivalent of this function in .NET world: AtlSetPerUserRegistration
Try this: Using regasm, generate the registry entries with /regfile argument. By default, registry entries should use HKEY_CLASSES_ROOT (HKCR) as a root. Modify the entries (manually, or by script) to use HKEY_CURRENT_USER (HKCU).
Finally, distribute your .NET DLL with the registry script. You can still run regedit without admin rights to register your .NET DLL. Manually from the command line, using a batch file, or a (tiny) separate installation program can handle the registration.
Admin privileges are required to allow Regasm.exe to update the registry. If this is a UAC restriction then create a shortcut on the desktop for cmd.exe and check the "Run this program as an administrator" checkbox. Or change this setting on the Visual Studio Command Prompt shortcut, that's easier.
I think this question belongs elsewhere, but Windows uses least privilege so if he is a user that is both a normal user and an Administrator than he gets normal user privileges. Use runas to make this work or right click the item and "run as administrator"
Why don't you use registration free com? Its only been supported since 2003 and obviates the need for UAC / administrative access to install COM components.
With RegFree COM you can just bundle the COM dlls with the application that uses them as a private assembly - but that doesn't mean they can't be properly installed - either in the registry or in WinSxS by the final deployment install.exe/msi
Subtext wrt the actual query: no - COM registration is in the HKEY_LOCAL_MACHINE key that always requires administrative access.
I lied: Actually you can. If you create a application with no manifest at all, Windows deduces that its an XP era application that expects administrative access to run and will activate a compatibility mode that, amongst other features, redirects write access to HKLM to a writable location under HKCU. So the COM component registration "succeeds" - but is registered for the current user only.
Im not sure why the ability to register for just the current account isn't supported generally outside the compatibility framework.
Check this out: https://gist.github.com/florentbr/6be960752fc852ee99eece6b4acb8ba7
I was trying to do the same thing and was about to give up when I came upon it.
It's a cmd script that will register the SeleniumBasic.dll in the registry without having admin privileges. With a bit of work you should be able to repurpose the code to register your COM components.
Many, many thanks to Florent Breheret for SeleniumBasic and this cmd script to register it!
I am logged into an account that has Administrator privileges. But RegAsm.exe still says it needs Administrator privileges.
[From some notes I have for Windows 2008 R2. Confirm on other Windows operating systems that support UAC. The following assumes that you are permitted to make changes to the Local Security Policy. ]
In its default configuration, User Account Control (UAC) settings give the local Administrator full privileges, but restrict the privileges of other members of the Administrators group. To lift the UAC restrictions on other members of the Administrators group, do the following:
Select Start -> All Programs -> Administrative Tools -> Local Security Policy.
Select Local Policies -> Security Options.
In the right panel, double-click the third entry from the bottom which reads User Account Control: Run all administrators in Admin Approval Mode.
Click Disabled.
Click OK to close the dialog and close the Local Security Policy configuration tool.
Reboot the computer to complete this change to the UAC settings.