My company produces a tool that the user installs on the server prior to publishing their project. For Azure deployment we have a startup script (a simple .cmd file) that installs our tool. It has the recommended checks for repeat runs, and logs everything. The problem is that the user can't tell if there was an installation problem without RDPing to the role instance and checking the logs.
My question is: if there is a failure installing our tool is there any way to report it back to Visual Studio?
I don't believe there is. If I recall correctly, the startup tasks are fired off as part of the role's startup process (depending on the startup task type - simple, background, etc.). That script is running along with other things like the plug-in that configures Remote Desktop (which I believe the plug-in is a specially packaged type of startup script). I don't think there is anyway to report back (to whatever initiated the deployment operation) what startup tasks failed.
Related
Windows 10 has a new sandbox which is based on a very small and fast Hyper-V VM. With every start of the sandbox you get a "fresh" Windows and on every sandbox termination, all changes are discarded.
My question is: Is it possible to define in which state the sandbox starts? E.g. is it possible to start the VM with pre-installed reversing tools or a script that is automatically run, as soon as the system is booted?
Use case: Due to it's fast start-up time and "throw away" characteristics, the Windows 10 sandbox would be a dream for automated malware analysis.
You can somehow change the behavior of the sandbox. For example run a script at start up or disable network. See here for a how to: https://medium.com/#maarten.goet/how-windows-1903-makes-malware-analysis-easier-introducing-windows-sandbox-3ec791c8367
In general, sandbox startup can be controlled by a startup configuration file:
Windows Sandbox supports simple configuration files, which provide a
minimal set of customization parameters for Sandbox. ... Windows Sandbox
configuration files are formatted as XML and are associated with
Sandbox via the .wsb file extension.
The specific ability to execute a script upon sandbox startup is documented here: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file#logon-command
It says:
Logon command
Specifies a single command that will be invoked automatically after
the sandbox logs on. Apps in the sandbox are run under the container
user account. The container user account should be an administrator
account.
XML
<LogonCommand>
<Command>command to be invoked</Command>
</LogonCommand>
Command: A path to an executable or script inside the container that
will be executed after signing in.
Note
Although very simple commands will work (such as launching an
executable or script), more complicated scenarios involving multiple
steps should be placed into a script file. This script file may be
mapped into the container via a shared folder, and then executed via
the LogonCommand directive.
I have setup a startup task on my Azure Cloud Service for Web Role.
It executes a startup.cmd file which installs a third party S/W on cloud.
I have tested it on my local machine and it worked fine.
Now I have some questions about its execution on Azure Cloud Server:
Will startup task execute as soon as I publish my application on
server? Or I have to do something manually to get it executed.
How can I get information about execution of startup task? like it's
success, failure or is it executed or not? error messages and all.
Thank You
Answers to your questions from this link:
Will startup task execute as soon as I publish my application on
server? Or I have to do something manually to get it executed.
Yes. You don't have to manually trigger these startup tasks. Please see Role Startup Order section in the link for more details.
How can I get information about execution of startup task? like it's
success, failure or is it executed or not? error messages and all.
You can log the errors encountered during the execution of startup tasks in a directory specified by the TEMP environment variable. From the same link:
Your startup task can log information and errors to the directory
specified by the TEMP environment variable. During the startup task,
the TEMP environment variable resolves to the
C:\Resources\temp[guid].[rolename]\RoleTemp directory when running on
the cloud.
Startup tasks must end with an errorlevel (or exit code) of zero for
the startup process to complete. If a startup task ends with a
non-zero errorlevel, the role will not start.
I have an app which needs to be installed for all the services I have. Unfortunately, installation requires many files and task related input parameters (e.g. RoleInstanceValue xpath=...).
The way I came up with to share this task among cloud service projects is through Azure Plugins (here is a link to a library of them http://richorama.github.io/AzurePluginLibrary/).
The problems I see with this approach are:
It is not recommended/supported by Microsoft, which means they can
change support for that any time.
It requires copying files to C:\Program Files\Microsoft
SDKs\Azure\.NET SDK\v2.6\bin\plugins\NxlogAzureForwarder, adding an
extra step to build setup.
Microsoft recommends startup tasks. But I could not figure out a way to share them among cloud services.
So, my question is: how to easily reuse startup tasks?
As recommended your best chance would be a startup task that starts your app, which would be encapsulated into a Windows service. That service is going to be your reusable task/app/service (whatever you call it).
What you need extra is the following:
Project reference to your Windows service
An install script for the service
Installer tool
(Optional) app config for your service
To start your app/service you need to update cloud service definition by adding start up task and making runtime context elevated, and start your service in OnStart entry point.
That being said, you can place parameters of your app in the cloud config and read them in your WebRole and pass them to your service.
For more detail check out this post.
I have created web application and one agent (EXE) with it fetch performance counter using WMI Query (compatible with 32 bit) so i have created one Enable32BitAppPool1.cmd file and add it in startup task, content of that file as per below
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true
and set property of that file "Copy Always" as per following this link.
Now when i am going to upload that package to Azure then it will be Aborted or in Buzy mode
Can anyone please tell me the reason of this?
It seems your cmd file not working in startup task.
Two possible solution
1> Create .bat file and try in as a start up task for your webrole.
2> other solution is that, try to run the file (.cmd) using system.Diagostic.process.start(...) from some other exe file and set that exe file as a startup task.
There is absolutely no way to know, based on what you've posted, what's going on.
I'd enable remote desktop on that instance and check out the event logs to try and get a handle on what's happening.
If you can't remote desktop in because your startup task is killing it - then disable the startup task, remote desktop in, and try to run what you think the startup task is doing - but manually - so you can see what's actually going on.
Environment: TeamCity 6.5.1 on Win2k3, BuildAgent(s) on Win2k3, Visual Studio 2k10, .NET v4, Nant 0.91
I'm completing the setup of TeamCity and am trying to lock down the BuildAgent account on the build machine(s) per our security guidelines. The build is crashing the first time "devenv.exe /build" is called via the Nant script:
Faulting application devenv.exe, version 10.0.30319.1, stamp 4ba1fab3,
faulting module msenv.dll, version 10.0.30319.1, stamp 4ba1fd94,
debug? 0, fault address 0x0000c36b.
I had no luck googling that message. However, if I change the BuildAgent Service from the Local Network Account to the Administrator account, things work. However, if I use another domain account, it fails. Also fails if I add that domain account to the local Administrators group.
Any ideas on what I'm missing? Is there a specific privilege you need to have in order for a "DevEnv /build" to work without crashing?
Yuck, I just went through this recently. First, use devenv.com, not devenv.exe. The devenv with the com extension can build a solution and send all output to the console, without using the gui. As the TeamCity agent is a service, it may not be allowed to interact with the gui at all.
Second, and I realize that this might not be possible for you (especially if you are building an MSI), but consider doing whatever you need to do to use the built in Visual Studio build runner that comes with TeamCity. It does utilize MSBuild to do its work. If you go this route and you still need devenv, then go find MSBuild Extensions Pack, which has already solved a lot of these issues with their own devenv build task.
Honestly, I ended up replacing Microsoft's installation projects with alternatives (InstallShield or WiX), and never looked back.