I have a fairly simple WCF Role on Azure that I am trying to deploy two instances of - the role is fairly-well united tested and I've been able to run it successfully on the local emulator with no readily apparent issues.
The role has a couple of startup tasks that run in the background as the role starts, namely the installation of a pair of Windows Services that run asynchronously in the background doing data processing.
When I deploy the Azure, the first role instance boots normally and quickly, with the Windows Services successfully installed and running (I RDPed in to verify.) The second instance permanently hangs in a "Waiting for Host" state. I've tried rebooting that role instance individually and it doesn't appear to fix the problem.
I've also tried redeploying the entire package to Azure with the same results - first role instance starts fine, the second hangs.
What can cause this problem? Where should I look to try to fix the issue?
So ultimately I resolved this issue by turning to Windows Azure support - turns out I was being consistently deployed onto a "bad node" which I didn't think was possible given how the Fabric Controller works.
Nonetheless, if you run into this issue - Azure support is your best bet.
Related
I have a gMSA service account running a stateless Service Fabric application. The account has recently been added as a member to a new security group. We don't see that the application is working and I think its because the user claims were loaded on application start up. I've seen that to get this to work on Windows Services that we need to restart the service (mmc->Services, right click restart). I would like to do something similar in Service Fabric.
I see the option of restarting the node, but that is a more heavy handed approach than I want to use. This is in production and I want to scope the solution to the problem. The other applications on the node do not have an issue so I would prefer to not bring them down.
Service Fabric Deactivate (pause) vs Deactivate (restart)?
Thanks in advance,
Greg
What you are looking for is the Restart-ServiceFabricDeployedCodePackage command.
The Restart-ServiceFabricDeployedCodePackage cmdlet ends the code package process, which restarts all of the user service replicas hosted in that process. This restart simulates code package process failures in the cluster, which tests the failover recovery paths of your service.
You can specify a code package, or you can specify a ReplicaSelector to restart the node and code package combination where the replica is hosted. This simplifies tests on the primary host node by not having to determine which Service Fabric node is the primary node before restarting that node.
I have created a task using automation anywhere to run automatically at specified times and the schedule kicks off well until i logon to the machine remotely using vpn access, when i start loging on to the machine using the vpn my automatic schedules stops working after that, what could be the cause of this issue and how do i resolve it? the machine currently runs windows 7 enterpise.
Kind Regards,
Reuben Kekana
Given your information, the first thing that comes to mind:
When you log into the environment hosting the bot, you essentially 'steal' the connection from the AA control room. When you then disconnect from the environment, neither you nor the control room have an active session to this environment. This in effect means the environment 'logs off' and thus no longer runs any scheduled tasks.
You would need to go to the control room and re-establish this connection.
I'm involved in a project where, by adopting DevOps approach, a software (a Windows service acting as agent) has to be installed on the target servers to allow performing deployments remotely and autonomously.
As background, we are talking here about a server managing the deployments remotely, different target servers (Windows 2008 R2) where the code is deployed. The servers are hosting IIS applications and the deployments consist in just replacing files and folders followed by app pool recycle.
For this, I'm trying to apply two different kind of permissions: NTFS permissions on the application folder structure and permissions to recycle the App Pool.
It's on the last one where I have problems. I spent several hours searching on internet about this matter, but I'm unable to figure out how to properly do this, if it's even possible.
Almost all references (like bellow ones) are focused to IIS remote administration delegation or remote web deployments, which I tried unsuccessfully to apply.
What I need to know in fact is how to delegate the permission (to just recycle an App Pool and only that) locally on the server (for the account running the agent).
https://blogs.msdn.microsoft.com/asiatech/2011/07/20/iis-7-delegate-remote-application-pool-recycling-for-non-administrator/
https://www.iis.net/learn/manage/remote-administration/configuring-remote-administration-and-feature-delegation-in-iis-7
We ended up resolving this problem by using a second account with adminitrator privileges and a scheduled task.
So, we started with:
A Service Account (A) running the DevOps agent, with limited privileges.
A Service Account (B) running the scheduled task, with administrator privileges, to recylce the application pool.
And we did:
Created a scheduled task with A, so it is the actual owner of the task and have the necessary rights to run it.
Configured that task to run as B, which, as having adminitrator rights, will have the necessary rights to perform the application pool recycle.
This method will allow us to impersonate aditional administrator tasks for which there is no possibility to delegate permissions (or not easily).
Using Vagrant+Chef Solo I'm setting up two VMs: #1 is a TeamCity server, #2 is a TeamCity agent. Provisioning is done by first installing the TeamCity server package on VM #1, then the agent VM is booted and requests data from the server which is used to install the agent. That whole thing works fine.
But now I want to alter the server after the agent is done provisioning. I want to modify the server's database directly, to change an attribute that is only available after the agent has spun up. But is there a way for one VM's provisioning to trigger another VM? Once the agent is done I'd like to somehow resume provisioning the server, so I can make the database edit..
Any thoughts, recommendations, or feedback welcomed. I'm new to Vagrant, Chef, and TeamCity, so there's a chance I'm missing a much easier solution.
* Why do I want to edit the DB directly you may be wondering? TeamCity agents must be authorized before they can be used, and I want to do this programmatically. The solution I've found is to directly edit the DB, because authorization functionality is not exposed via the TeamCity REST API (as far as I can tell)
If you can test the agent is installed/answering, you may add a ruby block looping over this test before continuing the recipe execution.
This loop should have a sleep and a counter to avoid infinite loops.
I've no knowledge of teamcity, so can't tell if it's the best way.
In general, Chef is designed to manage your system, not simply provision it (though this is less true in the modern Cloud world with "golden image" strategies). Nonetheless, in your case, you best bet is to just setup chef-client as a service that runs every 15 minutes. Once the client has finished provisioning, the next run of the server will be able to authorize it.
If you really want to "trigger" the one from the other, you'd need either do that externally with something like etcd or consul, or you would need to setup an ssh keypair between the boxes and add a ruby_block on the client that either does the database modification directly, or calls chef-client on the server.
When I start a Weblogic instance with a deployed application, the deployment is sometimes left in prepared state, not in active state. I have to go to Weblogic Console and start the deployment manually, which is quite slow and annoying repetetive work. Since this is done on a development machine — sometimes 50 times a day, — there are no security implication as the server is only visible on the local network. Is there some way to have it always start the deployment active?
Note that I'm not redeploying the application, I instead have it "constantly deployed" and stop/start the Weblogic instance using the scripts in bin directory.
If you are running weblogic in development mode, you can use the autodeploy folder for your app. See details here: http://download.oracle.com/docs/cd/E11035_01/wls100/deployment/autodeploy.html#wp1021620
Think this should solve your problem