when we can manually connect to remote desktop and install software we desire, why we need extensions? Custom Script extension and Desired State configuration works same way. They run the same powershell script. why do we need many extension that basically does same thing. Please give me an idea on this.
when we can manually connect to remote desktop and install software we
desire, why we need extensions?
You can connect to remote desktop to install software, but sometimes if you can't connect to it, you can use custom script extension to install it, or change some configuration.
For example, if you can't RDP to windows VM(RDP service disabled), you can use custom script extension to enable it.
Custom extension will use wagent to run this script.
Main reason to use those - automation. How would you connect to 10000vms and install same software? What time would it take you? How many errors will you make?
This question is basically asking - what is the purpose of automation? we can do the same thing manually. Well, good luck with that :)
Related
I am the developer of Planner and I am having a problem assigning a keyboard shortcut to the current system.
Planner is a task manager and has a built-in application called Quick Add that through a keyboard shortcut that can be run regardless of whether Planner is running.
To install this keyboard shortcut I use the following service.
This works perfectly if I build Planner from the repository. However, I have an error if I execute the same function if I build Planner from Flatpak
** (com.github.alainm23.planner:2): WARNING **: 15:54:36.510: CustomShortcutSettings.vala:28: Schema "org.gnome.settings-daemon.plugins.media-keys" is not installed on your system.
I know that I can't access the scheme of org.gnome.settings-daemon.plugins.media-key And I need a hole to edit the dfcon configuration of the system.
The question is how can I do that. If anyone could help me I would be very grateful.
Flatpak by default doesn't allow editing GSettings in a way that affects the rest of the desktop, since rouge applications could use that ability to do things with security and privacy implications, like set or unset proxy servers.
So it would be best to look into alternative ways to make this possible - perhaps provide people with instructions to set it up manually, or request and/or contribute proper portal support for setting global keyboard shortcuts.
If you still really want to implement this, check the link above for the details on the sandbox hole you need to open to make it work.
this is my first time on such a prestidigious site, so please welcome me by assisting me. I am doing independent development and am primarily a music designer. So that is why I may not sound like a real pro coder but nevertheless truly love creating my music through automative processes.
My present issue is this:
Windows 8.1 Pro
AutoHotkey 1.0.48.5 32bit (running as Admin)
Everytime I attempt to use the command 'RUN' with an .ahk target, I get the expected result except that the .ahk residing folder is opened by MS Explorer. I suspect that something like the fact that AutoHokey is an unsigned app, windows does not want it to run flawlessly. I am now trying a number of Administrative Tool Services disabling, but with no success yet.
RUN C\:XZN\Mecanisms\AnyAHK_script.ahk
;;or
RUN AnyAHK_script.ahk, C\:XZN\Mecanisms
;;or
RUN C\:XZN\Mecanisms\BactchfileLaunchingAboveScript.bat
;;or
RUN AnyAHK_script.ahk, C\:XZN\Mecanisms
Would there be a workaround this at the OS settings level or another way to run/start an .ahk file?
I tried the 'Comspec' approach as well as running an .ahk from within a batchfile, but the .ahk always get intercepted whenever it contains a 'RUN' command requesting an .ahk target.
Thanks.
You are using outdated version of AutoHotkey which is more than 5 years old. Always use AutoHotkey and its documenatation from http://ahkscript.org/ (current uptodate version, new official website)! AutoHotkey and its documentation from autohotkey.com is outdated and you may have some problems using them!
One thing to try if you only have this problem on win 8 is to Enable interaction with administrative programs http://www.autohotkey.com/board/topic/70449-enable-interaction-with-administrative-programs/
That script modifies the executable file's embedded manifest, then creates and installs a self-signed certificate and uses it to sign the file. The executable will not run on any other system, unless you install the certificate used to sign the file.
But lets see some script code that way we have something to test with and can better help you out...
If the C# application is on the same server as sharepoint, I know we can use RunSpace to run the pwoershell script, but what if the C# app. and sharepoint server are on different PCs?
Is this possible?
thanks
yes, its possible, though messy. In Powershell 2.0+, there's a feature called remote powershell, so you can effectively, via c# code, send Powershell commands to your local powershell instance, and use that to log into the remote instance.
A slightly less insane idea would be to simply create a web service on the remote machine, and have that run the remote powershell commands, from the web service.
And even less crazy idea is just to write a web service, and have that run code on the remote server. : )
Good luck!
If you are administrator on the remote box, you can try combining PsExec and PowerShell.
I am currently trying to implement a one-click build solution (without having to start the monodevelop IDE) for my monotouch projects, where i could specify provisioning profiles and code signing certificates. I searched popular build tools like nant, ant and maven, but none seems to support monotouch. Has anyone tried something similar ?
I've gotten it work with Jenkins (aka Hudson).
You basically setup a Jenkins server, and setup your Mac as a "slave" build server. (I used a JNLP slave).
From there you can run any command line you want in the build, so you merely have to run mdtool with some arguments, like so:
/Applications/MonoDevelop.app/Contents/MacOS/mdtool -v build "--configuration:Release|iPhone" "Path/To/YourSolution.sln"
One thing to worry about is that to sign an iOS app, the slave process must run under your user. So you can't really create a Mac daemon for it, you'll have to run the slave process in startup for your user and minimize it, which is kind of annoying.
You tried teamcity? Might be worth you having a look at this thread Buildserver for MonoTouch upon OS X?
Thx for your answers. However i don't need to use such heavy artillery in this case. Since i'm developping a single and small app, I ended up by creating 3 different Build configurations in my solution, because i found out that it is possible to configure different codesign identities and provisioning profiles for each one (Development, Ad-Hoc, AppleStore), in the monodevelop project options menu.
Then in the AppleStore/Ad-Hoc configuration, i added post build commands, so i could create the .ipa file automatically (basically create a "Payload" folder and copy the .app file into it, and then zip it into a .ipa file, along with the icon and itunesartwork files).
Finally i created a bash script that invokes mdtool with any of the configurations, so i can build and generate .ipa executables by just executing the script.
I have a Windows Server 2003 running Mercurial's hgwebdir.cgi to serve repositories. Push/Pull etc is working as expected for existing repositories.
Currently I'm using remote desktop If I need a new repository on the server.
Is there a better way to do it? Command line, web interface, cgi?
Mercurial by itself only allows for the creation of repositories locally or over ssh. For http you need to either log in to the server via command line and hg init or via RDP and do essentially the same.
It is, however, very easy to create a small CGI script that will create new remote repositories over HTTP. Here's one I built that works on unix and is likely easily adapted to windows:
http://ry4an.org/unblog/UnBlog/2009-09-17
currently , running hg init where you want the repository is the way to do it, any other way would require hgwebdir to implement some kind of security better left to other/better/more os specific tools. It's not that much of a leap to imagine that the HG devs rather focus on the versioning of files than reinventing the wheel with security, at least right now.