is there an api to change the Access Permissions for the COM Security? i need to write new values to "Edit Limits..." and "Edit Default...". are these plain registry settings? can't find how to set these entries.
The quick answer is Yes they are registry settings, the long answer is No they are not simple registry settings. The values are binary and point to an ACL structure. In order to change these you need to load, update, and save the ACL (which requires a fair amount of code). The DCOMPerm sample in the windows SDK is a decent place to start, i have used it as a basis for a set of classes i use at work to handle this problem (Unfortunately, i am not able to release that code into the public domain)
You can review the MSDN Documentation for the DCOM key structure - that covers computer wide settings. COM application specific settings are stored under its APPID in the registry in the AccessPermission and LaunchPermission values.
Keep in mind that modifying the ACLs for the machine wide settings can quickly render your machine unusable if you do it incorrectly. If i remember correctly, you can simply delete the values (via RegEdit) and the OS will restore defaults to bring your machine back... but i'm not 100% certain on that anymore.
EDIT: The binary data is actually a Security Descriptor, but ultimately its the contained ACL that needs to dealt with - the SD just adds one more layer of code when unpacking/packing it.
Related
My task: to move the directory containing the databases and filesystems for a Ravendb-installation from one drive to another (because of disk-space issues) without moving or altering the Ravendb-installation itself.
I managed to move the databases by:
shutting down the Ravendb service
Moving the data-folder containing the subfolders Databasesand FileSystems
Opening Raven.Server.exe.config and changing the value for the settings Raven/DataDirand Raven/FileSystem/DataDir
Starting the Ravendb service again
Tricky part: going to some (not all) databases using Raven Studio and choosing Settings > Database Settings and changing the value here (again) for Raven/DataDir. So apparently, somehow, for some of my databases, this value was overridden in some metadata for the db itself rather than using the tilde to look relatively to the global setting (although the actual db or db definition or something was being loaded correctly, since I could even see this setting/value)
So far so good. But here the problem:
Apparently, too, for some filesystems (again not all), Ravendb seemed to think, their "data-data" was still in the old location (again, the actual filesystem metadata seemed to be loaded from the new location). But alas, filesystem do not have something similar to Database Settings in Raven Studio where I could change this data-dir, probably overridden here too.
The way I know the filesystems' data is assumed to still be in the old location, is that I can see new folders being created in the old location with the name of the respective filesystems.
I tried going to the system db (Main Window > Manage Your Server > To System Database), but the file-systems do not appear here.
So my question is: how can I change or set the Raven/FileSystem/DataDir setting for a single filesystem?
Eureka, I found this out:
The error was indeed, that for some reason, my filesystems do not appear in the system db when viewed in Raven Studio. I realized this, because the status-bar in the system db said 40 documents, but fewer were visible in the list. This must definitely be a bug in Raven Studio.
The solution: In system db, put my mouse cursor in the quick-goto-/search-field in the top ("Go to document") and typed Raven/FileSystems/ and from here on, the autocomplete would show me the available filesystems. Choosing the correct filesystem, I was now able to edit the (indeed overridden) path to the filesystem, which was set to an absolute path.
Note, that in general you should definitely use a path relative to the Raven/DataDir and Raven/FileSystem/DataDir settings, like e.g. ~\filesystems\my-db to more easily be able to move all dbs and fs'es around collectively.
I am in the process of building a completely fresh version of an application that has been in existence for a good many years. I can look back with horror now at some of the things I had done, but the whole point of life is to learn as we go along. The nice thing now is that I have a clean slate from which to work, and it's because of that that I thought that I would seek some advice from you all.
User settings are great for those things that each individual user would naturally want to and ought to be able to change, a theme or visual style for example. Application settings should quite obviously apply to the entire application irrespective of whoever uses it.
Somewhere in the middle though are a set of settings that I would like to give the system administrator the opportunity to change (default work periods, appointment time slots, the currency the company wants to use as its main trading one etc etc). These can't be user settings because individual users should not be able to change them, nor should they be application settings because I as the developer have no idea what the end user (or to be more exact the senior end user) would want to set them to.
Many years ago I might have considered writing such settings to the registry, or an ini file. I could perhaps (as this is an application that is tightly integrated with its own custom database) create a one off settings table, and read in the relevant settings at program startup. I could perhaps opt for a separate 'universal settings' xml configuration file stored in the all users directory. Clearly a number of options.
What I would like to try and establish though is the most efficient way to approach this. What is the best trade off between file read and write operations as against reading everything into a set of public constants at application start-up? These are not going to be settings that will only be referred to occasionally so efficiency is going to be key.
Just so that there is no ambiguity as to what the application will be. Traditional winforms, using vs 2012 as the development ide and vb.net as the code base based on .net4.5 and ef 5.0. Backend data to be stored in either sql express or full sql server. Target operating system for end users will be windows 7 or above (so due respect for the uac will be required).
I'd welcome any suggestions that you might have.
Is there a way (via shell extension or registry setting) to tell Windows Explorer that it shouldn't read files in the folder being shown in order to extract metadata or create thumbnails?
The problem is that when the user navigates to the folder, Windows Explorer attempts to read all files in the folder and extract certain metadata from them. If the medium is slow, this takes ages and causes unnecessary load on the file system. This is especially true in case of thumbnails, when the whole graphic file is read.
I am looking for ways to do this (restrict Explorer) in code, so "don't use Thumbnail mode" is not an acceptable answer :).
Upd: per-user settings won't work unfortunately cause we as a disk provider can deal only with our own disk (and the user might want to have separate settings for regular disks and virtual disks). I believe there must be some way to "explain" the OS that the drive is slow.
Maybe there's some IRP on driver level that we need to handle to tell the OS that the medium is slow?
Is there a way (via shell extension or
registry setting) to tell Windows
Explorer that it shouldn't read files
in the folder being shown in order to
extract metadata or create thumbnails?
Not that I know off, but depending on the priorities regarding the use case details you outlined there might be two options still to approximate the desired result:
Via group policy
Note that this essential expands/details the network folder related aspect of Freds answer, which you dismissed in your update; however, you claim to be able to deploy shell extensions or registry settings and the following two group policies simply execute the latter by administrative means:
User Configuration -> Administrative Templates -> Windows Components -> Windows Explorer:
Turn off the display of thumbnails and only display icons **on network folders**
Turns off the caching of thumbnails in hidden thumbs.db files.
This boils down to the following registry settings:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
"DisableThumbnailsOnNetworkFolders"=dword:00000001
"DisableThumbsDBOnNetworkFolders"=dword:00000001
Of course this is still not per folder, but at least limited to network folders and ignores regular disks and virtual disks.
Via hackish workaround
Given your statement we as disk provider can deal only with our own disk there might be a hackish workaround, though I'm afraid it lacks the last mile (untested by myself).
Starting from Chris W. Reas own answer to How can I suppress those annoying Thumbs.db files in Windows Vista and Windows 7?:
Also worth knowing: In Vista and Windows 7, Thumbs.db applies to network folders only. For local folders, Vista and Windows 7 instead save thumbnail cache information to a database in a local folder at "%userprofile%\AppData\Local\Microsoft\Windows\Explorer"
Continuing from there, Wil claims the following potentially clever solution to work on a per folder basis:
Go to the drive and create a file called thumbs.db (in notepad or anything), then change the permissions on the file for everyone (including SYSTEM) to deny all.
Unfortunately, aside from the automation requirements to create the dummy thumbs.db in each folder, the outcome depends on how Explorer will react on the inaccessible file - because caching is optional as per group policy, it might as well display thumbnails without caching them, making the bandwidth issue even worse in turn ...
Good luck!
I'm not sure if you can disable thumbnail generation/display for certain folders but this article talks about a script which could quickly disable it via context menu.
The script modifies a value in the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\. I suppose you could find something similar in that key for the other metadata. ShowInfoTip sounds promising. There might be relevant information in other nearby keys.
This may be a complete non-answer depending on your needs, but how about storing the files without file extensions that the OS wants to make thumbnails of? Call it file.jpg.abc and it won't be reading thumbnails, for sure.
I've got an Access 2007 database that I developed which connects to SQL Server for the actual data storage. I used the Package Solution Wizard to create a distributable installer which included access runtime (with an ACCDE file) which I went around and installed on 15 or so PCs. Anyway, my question is, what is the best way to distribute updates to this database? Right now I'd need to go around and remove and reinstall. That's not a problem... I was just wondering if there was another way.
I've tried leaving the front end on a network share but it seems that most people suggest storing the front-end on the local machine, which makes sense. The problems I've run into when I leave it on a network share (at least with Access 2003 mdbs) is that I find myself needing to compact and repair often and I also have to kill the open sessions (user's who have the file open) when upgrading. I would imagine it could also hypothetically create an unnecessary bottleneck if the user was not on the local network.
Automating front-end distribution is trivial. It's a problem that has been solved repeatedly. Tony Toews's http://autofeupdater.com is one such solution that is extremely easy to implement and completely transparent to the end user.
We developed a vbscript 'launcher' for our access apps. That is what is linked to on the start menu of user's pcs and it does the following.
It checks a version.txt file located on a network share to see whether it contains different text to a locally stored copy
If the text is different it copies the access mdb and the new version.txt to the user's hard drive.
Finally it runs the mdb in access
In order to distribute an update to the user's pc all that is required is to change the text in version.txt on the network share.
Perhaps you can implement something similar to this
Make a batch file on the server (network drive).
Create a shortcut link to that batch file.
Copy the shortcut to User's Desktop.
When user double-clicks on shortcut, it will copy a fresh copy from network to local.
Replace old database.adp on the server drive when you update a new version.
Each user gets a copy of database.adp on their machine.
Remove Security warning when opening file from network share is here.
Batch File
#ECHO OFF
REM copy from network drive to local
xcopy "Your_Network_Drive\database.adp" "C:\User\database.adp" /Y /R /F
REM call your database file - Access 2007
"C:\Program Files\Microsoft Office\Office12\MSAccess.EXE" "C:\User\database.adp"
This is a very old post and I used the autofeupdater until it stopped working so I wrote one of my own and it has evolved over the last few years into something that I have used with many clients. It's so simple to use and there is no interface. Just an EXE and a very simple config file.
Please check it out here. I can also help with custom solutions if none of the configurations work for your needs. http://www.dafran.ca/MS-Access-Front-End-Loader.aspx
After trying all of the solutions above (not exactly these solutions but these are the common suggestions in the Access community), I developed a system entirely within Access using VBA that allows an admin DB to create and publish objects to client DBs without the need for user intervention or management of multiple DB files.
This approach has several benefits:
1. It simplifies the development process by having a dedicated environment (admin DB) for development and testing totally separate from the client DBs.
2. It simplifies the update/distribution process by allowing a developer to push out updates in real time that client DBs can implement in the background, without involving users. Can also allow devs to roll back to previous versions if desired.
3. It could be used as a kind of change management system within Access for developers who want to commit multiple changes to objects and modules and retain past changes.
4. It allows for easier user access control by allowing an admin to easily assign certain objects to specific users/roles without needing to maintain multiple versions of the DB.
I will hopefully post the code to GitHub soon, I just have to get clearance from my workplace to release it. I will edit this post to include the link when I have.
We have usually kept the Access front ends on network drives, and just put up with the need to compact and repair on a regular basis. You will probably find you need to do that even when they are installed locally, anyway.
If you must have it installed locally, there are various tools which will enable you to "push out" software updates, and the guys over on ServerFault would have more information on those. Assuming such tools aren't available, the only other option I can think of is to write a small loader program that checks the local .MDB against a master copy on the server, and re-copies it across if they are different, before then launching the MDB.
While opening any MS Access database, a security warning appears saying that the file can be harmful to the computer. However, is there a way to remove this message. Or should it remain a necessary evil
You can probably sign your program. I don't know for sure. Read this article and see if the same principle applies.
If you lower the security settings in your Access options it will go away I believe. Of course those settings are set where they are for a reason.
Here are some more notes on certification and security.
Certification, including self-certification:
http://office.microsoft.com/en-us/access/HP010397921033.aspx
General information on security principals for Office code and macro security: http://office.microsoft.com/en-us/ork2003/CH011480831033.aspx
Trusted location defaults for Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403181033.aspx?pid=CH011480851033
Macro security in Office 2003
http://office.microsoft.com/en-us/ork2003/HA011403071033.aspx?pid=CH011480831033
You can eliminate the security warning at the startup of a ms-access project by putting the access project in a Trusted Location. Or Better yet, make your own Trusted Location.
I recommend creating a folder in the System (C) drive with the name of your project. For example, we could call the folder Database (Path: C:\Database)
Then enter this path as a registry key like this:
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted
Locations\Location20] "Path"="C:\Database" "Description"="Access
Project location"
Now lets explain a few things about what this key did:
The number "14.0" is the version of MS Office. You can simply change that to the number that represents the version you are running.
The "Location20" is a unique name that we assigned. The 20 can be any number that is not already used. Other programs, including default MS Access wizards, already may have used other numbers. Or if you want to make more then one path as a trusted location, then each location must end with a different number.
The "C:\Database\" actually is the physical path that you want to set to be a Trusted Location. You can put any path that you choose here. I am not sure why it uses double \, but I just copied the example of how the previous keys were set up and this seemed to work best.
The Description is not needed, but obviously any description can be used.
For more details on how to make Trusted Locations work for your MS Access project, read our detailed explanation here: http://blog.ideaz.net/2013/12/how-to-remove-microsoft-access-security.html
Here's my notes from a similar, internal issue with Access 2003 a few years back:
Okay, so here's (evidently) the deal.
The network server was not in the Trusted Zone. Starting, IIRC, with SP2, this causes a Open/Save/Warning box when opening a file. By default, UNC paths are supposed to be in the Trusted Zone. I'm not sure why it wasn't, but here's the fix: Add server.dns and server to Internet Options->Security Zones->Local Intranet.
Unsafe Expressions Are Not Blocked. This is some ridiculously overcomplicated Access security model (Google for unsafe expressions and Access Sandbox Mode for more). Basically, Access (starting with 2003 and/or Jet 4.0 SP8, I think) warns you if a registry key is not set to disallow "unsafe expressions". The fix: Set HKLM\Software\Microsoft\Jet\4.0\Engines\SandBoxMode to 3, which blocks "unsafe expressions" for anything using Jet. This has to be done by an Administrator. Alternatively, I think that answering "Yes" to the Block Unsafe Expressions prompt as Administrator sets that key for you.
This file may not be safe to open. This is an easy one, and follows the whole macro security model in Office. Just set the Tools->Macro->Security (don't look in the Tools->Security menu...that'd be too obvious) to Low.
BTW, I still have no idea what an "unsafe expression" is - nor why it continually asks to upgrade to Jet 4.0 SP8 when it already has been (I verified that it was updated by checking the file versions). But with those changes, it no longer asks anything when starting up. --MB
In Control Panel, click 'Internet Options'.
In the 'Internet Properties' popup, select the 'Security' tab.
Select 'Local Intranet' zone.
Click 'Sites' button.
In the 'Local Intranet' popup, clear the "Automatically detect..." checkbox and set the following checkboxes:
"Include all local (Intranet) sites not listed in other zones"
"Include all network paths (UNCs)"
'OK'.
'OK'.
Now all Access dbs anywhere on your Intranet or any referenced by a UNC will open immediately without warning. You assess the convenience/security tradeoff.