I have an requirement to execute macro-script kept on remote machine. DCOM Configuration setting is not set to allow communication between two computers. Even it's not possible to change the DCOM setting in my scenario.
Can I achieve the same requirement using Remote Desktop connection and then invoking macro script (through VBA code)?
I don't know exactly how to invoke script kept on remote machine using VBA?
Any idea/suggestions welcomed!!
This may not exactly answer your question, but may give you an idea.
I faced a the same problem with an application built in Access and the only way I could achieve this is by programming the macro I wanted to run into the application and then let the application periodically check a table on a share drive for "Go" command every few seconds.
On the share drive there was a table like this:
command_id | user | command
======================================
8 | "john.doe" | "update_me"
And all the applications were checking this table. If the app identified itself as user "john.doe", it decided to run the pre-programmed macro "update_me" and delete the row afterwards to prevent it from running again.
You can easily program more advanced stuff, like parameters, periodical execution etc.
It's not perfect, but it works quite nicely. Currently, I have the table on the SQL server and the command request takes cca 0.01s and I use it very often.
Related
My goal is to write to a file (that the user whenever the user launches an application, such as FireFox) and timestamp the event.
The tricky part is having to do this from the kernel (or a module loaded onto the kernel).
From the research I've done so far (sources listed below), the execve system call seemed the most viable. As it had the filename of the process it was handling which seemed like gold at the time, but I quickly learned that it wasn't as useful as I thought since this system call isn't limited to user-related operations.
So then I thought of using ps -ef as it listed all the current running processes and I would just have to filter through which ones were applications opened by the user.
But the issue with that method is that I would have to poll every X seconds so, it has the potential to miss something if the user launched and closed an application within the time that I didn't call ps -ef.
I've also realized that writing to a file would be a challenge as well, since you don't have access to the standard library from the kernel. So my guess for that would be making use of proc somehow to allow the user to actually access the information that I'm trying to log.
Basically I'm running out of leads and I'd greatly appreciate it if anyone could point me in the right direction.
Thanks.
Sources:
http://tldp.org/LDP/lkmpg/2.6/html/x978.html (not very recent)
https://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-4.html
First, writing to a file or reading a real file from the kernel is a bad idea which is not used in the kernel. There is of course VFS files, like /sys/fs or /proc, but this is a special case and this is allowed.
See this article in Linux Journal,
"Driving Me Nuts - Things You Never Should Do in the Kernel" by Greg Kroach-Hrtman
http://www.linuxjournal.com/article/8110
Every new process that is created in Linux, adds an entry under /proc,
as /proc/pidNum, where pidNum is the Process ID of the new process.
You can find out the name of the new application which was invoked simply by
cat /proc/pidNum/cmdline.
So for example, if your crond daemon has pid 1336, then
$cat /proc/1336/cmdline
will give
cron
And there are ways to monitor adding entries to a folder in Linux.
I wrote a small program in vb.net and I'm looking for a simple way to keep people from just copying the executable and running it on another machine for reverse engineering without the installer. I understand that if people want the program bad enough they will figure out a way to get a hold of it, I'm basically just looking for some kind of deterrent to keep our competitors from walking around and copying it.
Logan,
The bad news is that you cannot stop people from reverse engineering your desktop application. You have 2 options:
Create a web application instead. The code will run securely on your server.
Use Remote Desktop Services. This way you can install your program on your server and let the users use it via RDS. Here is an article that illustrates the concept and how to implement it on Microsoft Azure: https://technet.microsoft.com/en-us/library/cc755055.aspx
The standard approach is to create a license key that will only work on a specific machine and store it in the registry. This can be something as simple as:
When your app starts get a unique machine id (http://www.dreamincode.net/forums/topic/181408-get-unique-machine-ids/)
Perform a one way hash on it
See if this value is stored in the registry
If it isn't, display a dialog displaying the unique machine id and asking for the 'license'
Accept input of the license so they don't need to ask again
You can manually calculate the one way hash yourself for computers that you want to run the software on.
This won't stop a determined hacker but it'll keep the 99.9% of people who can't hack your software honest.
I created a time recording program in vb.net with a sql-server as backend. User can send there time entries into the database (i used typed datasets functionality) and send different queries to get overviews over there working time.
My plan was to put that exe in a folder in our network and let the user make a link on their desktops. Every user writes into the same table but can only see his own entries so there is no possibility that two user manipulate the same dataset.
During my research i found a warning that "write contentions between the different users" can be occur. Is that so in my case?
Has anyone experience with "many user using the same exe" and where that is using datasets and could give me an advice whether it is working or what i should do instead?
SQL Server will handle all of your multi-user DB access concerns.
Multiple users accessing the same exe from a network location can work but it's kind of a hack. Let's say you wanted to update that exe with a few bug fixes. You would have to ensure that all users close the application before you could release the update. To answer you question though, the application will be isolated to each user running it. You won't have any contention issues when it comes to CRUD operations on the database due to the network deployment.
You might consider something other than a copy/paste style publishing of your application. Visual Studio has a few simple tools you can use to publish your application to a central location using ClickOnce deployment.
http://msdn.microsoft.com/en-us/library/31kztyey(v=vs.110).aspx
My solution was to add a simple shutdown-timer in the form, which alerts users to saving their data before the program close att 4 AM.
If i need to upgrade, i just replace the .exe on the network.
Ugly and dirty, yes... but worked like a charm for the past 2 years.
good luck!
What are the risks of running an exe on an sql trigger? This is a closed server, intranet only, with limited user access to the server where the script runs from and the SQL server connection.
I store outgoing emails temporarily in a table in my database system. These are then sent out via a trigger that runs and exe. The exe simply pulls the to, from, subject, cc, and body from the DB and send the email via CDO.
I have to use an outside method of sending emails instead of simply sending from code-behind in order to avoid slwodown on the website. I asked regarding this specific issue in another post, but asking about exec risks seemed like a seperate issue. Direct any alternatives to the related post.
Related post Email from web without tying up webpage
If it's a closed server and the .exe is known, I don't see that there would be much risk if any. The only risk I could see would be if someone changed your exe for something else that would then be triggered, but that seems unlikely given the scenario you described.
We had a similar situation several years ago where we had a vendor whose product was updated via a control program. We had a trigger that hit the control program each time a user was added to the sql database, and the control program would then signal its service to add the user there as well. Never had a real problem with it.
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.