We have several Windows network shares, in a common location (\\server-name\share) that hosts a common set of files. These shares are replicated across roughly 300 hundred servers. We have the actual replication down, but we're running into an unanticipated problem: server admins half the world away changing file permissions on our share, and breaking replication in creative ways.
To detect this early on, we'd like to write a script to check each server's network share and ensure that a few permissions exist for the share folder & its contents:
Everyone needs read access
User X needs change/modify
User Y needs full control
Now, so far I've got a nice script that checks that at least each share exists. The complication stems from the fact that (due to a nice Active Directory tree), the usernames are consistent across servers (always of the form "DOMAIN/user"), but their guid numbers vary.
So far I've been looking at cacls.exe and the newer version Icacls.exe, but the options are confusing and seem to be centered around changing the Access Control Lists, which I don't want to do. Any tool that's Windows built-in is preferable, I'm just unsure how to approach this.
So it comes down to is: on some arbitrary server, if I only know the NAME of a user, is there a way to figure out what file permissions they have on a given folder?
icacls does allow the use of the "friendly name" form for specifying the user. Which means you should be able to use the human style names. So 'bob' should point to the same person in all of your domains.
You can grant a user a permission without changing anything else using /grant:r which means "if it's already there do nothing, otherwise add it". So,
Everyone needs read access
icacls \a\directory\somewhere /t /grant:r Everybody:(rd)
I assume you want them to be able to list the contents of the directory as well as read.
User X needs change/modify
icacls \a\directory\somewhere /t /grant:r bobX:m
And so on. I assume that 'm' is sufficient to convey the 'modify' permission.
ACLs are just another name for "permissions". So, if you want to change permissions then you want to change the ACLs.
Related
I am trying to split an Access database where I work but I have encountered a few issues that I am struggling to resolve. If I can first explain the problem.
I work for a large multi-national company that has on-site IT support but does not support Access (so no help there)
There are 12 of us working in our section, we have an old and badly designed StockMaster database on the networked F drive. The problem is that it is only set up for single users, we have to take turns using it. We aren't a computer savvy bunch, we tend to run the same named queries on a daily basis
The database is only updated once per day, every morning we get a download from our colleagues in Amsterdam. I do not want to play around with this database as first of all I'm no expert and secondly if I break it, no one will fix it.
My plan is this;
I have created a new Access database StockMaster2 that imports the required tables. Using VB coded modules, is deletes the old then imports the new. Therefore every morning it replicates what is in the original database and it works fine.
My next step is to split the database, create the front end and distribute. This is where I'm having problems.
I created the original front end StockMaster2_fe.accde and placed it in the database folder on the F:\ drive. Does every user get their own copy of the front end? I copied and saved two more front ends (copy and paste in the same folder -> rename) namely StockMaster2_alan_fe and StockMaster2_ryan_fe and tested it. I told Ryan (who sits next to me) to find the front end named after him on the F:\ drive and open it whilst I was in ...alan_fe. We both went to run macros at the same time but he was kicked out as it gave me exclusive access.
What am i doing wrong? Why is it not allowing multiple access?
My problem is that due to strict administrator privileges I cannot download any software or access the command line, so anything that I do must be done in Access itself
I apologize for not seeing this post sooner to end your agony. There are two absolute main issues that must be resolved to get you on the right track. First, and perhaps the most important, is that your file has the name of StockMaster2_fe.accde. The extension, the accde, is the executable version. Design changes cannot be made to that version. The extension should say .accdb to provide you with all the flexibility to alter the database, create one database for back-end tables, and a second database for front-end objects to include queries, forms, reports, macros and modules. If you have the accdb version, then your work will start to get much easier.
Issue number two, if your team is not able to share the database, then that is a sign that the database, when first opening, is opening in Exclusive mode. This option can be changed in the Access Options, in the Advance menu, under Advanced section. Look for Default open mode. It should say Shared to have multiple users operating all at once.
A possible hidden issue that can be happening, is that the database has VBA code which informs the database to open exclusively. With your version of the accde, you will not be able to access that code or change how the database opens.
Let's break this down (only because I finished all my work already...):
My next step is to split the database, create the front end and distribute. This is where i'm having problems. I created the original front end StockMaster2_fe.accde and placed it in the database folder on the F drive. Does every user get their own copy of the front end?
Yes
I copied and saved two more front ends (copy and paste in the same folder -> rename) namely StockMaster2_alan_fe and StockMaster2_ryan_fe and tested it. I told Ryan (who sits next to me) to find the front end named after him on the F drive and open it whilst i was in ...alan_fe. We both went to run macros at the same time but he was kicked out as it gave me exclusive access. What am i doing wrong?
Ensure your back end contains only tables. Access is a "client-centric" database, which means when a query is run it pulls all of the data over the pipe to your local computer, does what it does, and then sends it back. So, make sure the back end has only tables and all the other jazz (macros, queries, etc...) are in the front end. Also, the front end will contain links to the back-end tables. All of your queries/macros/etc.. will reference these links, and not the tables in the back-end DB directly.
Why is it not allowing multiple access?
Also, make sure your table-locking scheme is multi-user friendly. If you're doing table locking, it will cause errors. If you're doing record locking, it probably won't.
My problem is that due to strict administrator privileges i cannot download any software or access the command line, so anything that i do must be done in Access itself.
Shouldn't be a problem at all.
I am asking this in relation to this question: Batch: find file and rename it / find file and delete it
I am trying to do the same thing, except as the question states, I am trying to list all the users in and set each one to a variable, put a link to my program into the startup, then go to the next user, and do the same, but the users vary from workstation to workstation. So I need it to look at the folder name (in relation to the user account name of course) and use it as a variable in the xcopy command.. I am in a rush writing this, so let me know if you need any clarification, hopefully it makes sense. Thanks to anyone who helps! :)
Sounds like the Rube Goldberg method of software deployment. Just put a link to your program into the All Users profile.
copy shortcut.lnk "%ALLUSERSPROFILE%\Start Menu\Programs\Startup\"
...and done.
I shudder to think of the maintenance nightmare your intended self-prescribed solution would cause. What happens when a new version of the software needs to be deployed? What if the updated version defaults to installing in a different directory than the previous? What happens when a user gets a new computer and hands-me-down the existing one to an intern / GA / lower-level peon? Goes on vacation and someone else fills in temporarily? You really should do the "All Users" thing.
Or even better, include it in your domain policy login script.
I have an windows application (WPF) in which we are running on each login, however when the user first logs into a new PC the application will need to do some specific tasks, but only on the users first login and never on subsequent times.
Is there a way in .Net 3.5 to query wether the user has logged in before (ie some kind of login count)?
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
We use redirected folders so the user may have already logged into a PC on our network these special events should only occur when the user hasnt logged in onto the PC and Windows has had to create a new profile for the user on the PC.
If I am not clearly explaining what I am seeking, please dont hesiate in letting me know.
Matt
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
I'd recommend going with this option. Don't try to detect it, just create your own state on first run.
I suggest this, not because it is technically impossible to achieve the functionality you describe, but because it is a better user experience. It provides an easy way to re-do the action without having to recreate the user.
... a txt file in the users registry ...
I'm not sure what this means. You can create text files under the user's profile directory, and you can insert string values in the registry (but not files of any sort).
As for the particular mechanism, I suggest you consider:
An App.Config value. Clearing out the value is easier to support or batch-script than a registry value, and makes the user less scared that their machine will explode if you have to tell them to edit the settings. Users are scared of the registry.
A sentinel text file under the user profile directory. Wiping out the file is super-easy to support and batch-script. Instead of editing a text file, they can just delete one. But this makes it so you have multiple config mechanisms, so multiple points of failure. I'd only do this if I were using the App.Config for additional settings in the program and thought the user wouldn't be technical enough to hand edit it.
The windows registry. Remote registry access might be easier than remote file access, if you're having to do remote troubleshooting. It also might be easier to mess with via group policy, in case this is an intranet app and you need to force a re-run on all machines in your org.
I'd carefully consider my options and which is most likely to ease support (be understandable by my users) before committing to one. I'd also consider the remote-troubleshooting/remote reset scenario.
This may not be what you're looking for but I'm hoping it will help you anyway.. I do not know from the top of my head how to do this in WPF but I do know you can use an "unattend.xml" file and the FirstLogonCommands to execute a script or application on first logon. I have used this for Windows 7, it may not apply to XP.
I'm creating a little app that configures a connected device and then saves the config information in a file. The filename cannot be chosen by the user, but its location can be chosen.
Where is the best place for the app's default save-to folder?
I have seen examples out there where it is the "MyDocuments" location (eg Visual Studio does this).
I have seen a folder created right at the top of the C:\ drive. I find that to be a little obnoxious, personally.
It could be in the Program Files[Manufacturer] or Program Files[Product Name], or wherever the app was installed. I have used this location in the past; I dislike it because Windows Explorer does not allow a user to browse to there very easily ('browsability').
Going with this last notion that 'browsability' is a factor, I suppose MyDocuments is the best choice. Is this the most common, most widely accepted practice?
I think historically we have chosen the install folder because that co-locates the data with the device management utilities. But I would really like to get away from that. I don't want the user to have to go pawing through system files to find his/her data, esp if that person is not too Windows-savvy.
Also, I am using the .NET WinForms FolderBrowserDialog, and the "Environment.SpecialFolders" enum isn't helpful in setting up the dialog to point into the Program Files folder.
Thanks for your input!
Suz.
User data belongs in the user's folder. The (utopian) idea there being that they need only back up their personal folder, and should their computer die a sudden fiery death they would have everything they need to get their computer back up in working order. If all their personal data is scattered across the computer it only serves to confuse the user and destabilize your product.
Opinion: all this documents-and-settings stuff with lots of spaces inside is really misguided, including "my" documents. You always end up having to type it manually at the command line. I would choose a NIH structure under user's harddrive, he will only say thanks.
I want to make a WPF application that exists in one directory including all files that it needs: .exe, .mdf database, .xml config files, etc.
the application should work no matter what directory it is in so that it supports this scenario:
person 1 executes the application in c:\temp\wpftool.exe
the application reads and writes to the c:\temp\wpftool.mdf database
person 1 zips up that directory and sends it to person 2 via e-mail
person 2 unzips it to c:\Users\jim\documents\checkout\wpftool.exe, the application reads and writes to the same database in that directory (c:\Users\jim\documents\checkout\wpftool.mdf)
person 2 zips the directory up again and sends it back to person 1 to continue making changes on it
What is the best way to create a WPF application that supports the above scenario?, considering:
there should be no hard-coded database connection strings
what is the best deployment method, click once? or just copy the .exe file out of the /release directory?
reasonable security so that users have to log in based on passwords in the database, and if a third person happens to intercept the e-mail, he could not easily look at the data in the database
Some points on the database side:
Assuming the "New user" already has SQL installed, they'd need to attach the (newly copied) database. Besides having sufficient access rights to attach a database, your application would need to configure the call to include the drive\folder containing the database files. If your .exe can identify it's "new home folder" on the fly, you should be able to work that out.
Define "reasonable security". Any database file I get, I can open, review, and ultimately figure out (depends on how obscure the contents are). Can you obfuscate your data, such as using table "A" instead of "Customer"? Would you really want to? The best possible security involves data encryption, and managing that--and in particular, the encryption keys--can be a pretty advanced subject, depending on just how "secure" you want your data to be.
For the database, I would look into using the "user instance" feature in SQL Express. Combined with the |DataDirectory| substitution string support it makes it very easy for your application to get hooked up.
In all honesty I have not deployed a ClickOnce app leveraging this approach myself yet, but I just thought I would bring it to your attention because it's what I would look into myself if I was building something like you described.