Startup tasks

Mar 5, 2013 at 5:53 AM
Hi David,

I have 4 working cloud services that have all mysteriously gone down.

One change I have recently made is configure smtp which I didn't on initial deployment.

Azure engineers have picked up

I saw three startup tasks in your application, and get the following error message in Event log which will block web role to start:

User program "E:\approot\bin\scripts\SetupIISRemoteMgmt.cmd" exited with non-zero exit code 2. Working Directory is E:\approot\bin.

So question is is there any 'dormant" startup tasks that would only fire in the event of configuring smtp?

Interestingly it has been aprox 24 hours after I setup smtp was working fine between then & about 4 hours ago.

Thanks
Mar 5, 2013 at 6:22 AM
Further update from Azure Engineers

Here is a quick update, as we talked over the phone, the startup task (E:\approot\bin\scripts\SetupIISRemoteMgmt.cmd) is executed with non-zero exist code 2, which will block the web role from starting. As a simple test, I manually edit this startup task to add exist o code which seems worked out the problem, and I can see the two web sites are successfully created in IIS web server, and the role enters into Ready state.
Mar 5, 2013 at 6:33 AM
Wow, that’s it. To be specific, “net start wmsvc” command code returns error code 2 if the wmsvc service is already running. You could either add “EXIT /B 0” at the end of file to work around the issue, or add a logic to determine if the service is already running, and then perform next operation.
Coordinator
Mar 5, 2013 at 10:00 PM
Good catch @tango,

I have added the EXIT /B 0 in the three startup tasks (in fact is a good practice). The redirection for the stdout and stderr were there for debugging the execution result, but was missing to "hide" the ERRORLEVEL on exit. I have done the changes and checked-in.

Don't know how this happened but I'm interested in to discover possible scenarios. Can you tell me:
  • Which package and version are you using? (I'm supposing a minimum of 6.3 but perhaps you have downloaded and build the latest version)
  • OSFamily? (I'm supposing you are using "2" depending on before)
  • Can you go to the WADLogsTable on Azure storage and look for activity just when this occured?
Thanks!!!
Mar 5, 2013 at 10:09 PM

Thanks ill get back to you with info.

In the meantime what do I do to permanently fix the existing 4 cloud service deployments I have?

Is there some config file or something I need to upload & run?

Regards

Todd

From: davidjrh [email removed]
Sent: Wednesday, 6 March 2013 10:01 AM
To: Todd Lane
Subject: Re: Startup tasks [dnnazureaccelerator:435387]

From: davidjrh

Good catch @tango,

I have added the EXIT /B 0 in the three startup tasks (in fact is a good practice). The redirection for the stdout and stderr were there for debugging the execution result, but was missing to "hide" the ERRORLEVEL on exit. I have done the changes and checked-in.

Don't know how this happened but I'm interested in to discover possible scenarios. Can you tell me:

  • Which package and version are you using? (I'm supposing a minimum of 6.3 but perhaps you have downloaded and build the latest version)
  • OSFamily? (I'm supposing you are using "2" depending on before)
  • Can you go to the WADLogsTable on Azure storage and look for activity just when this occured?

Thanks!!!

Mar 6, 2013 at 1:53 AM

Hi David,

Im using Version 6.3 - 08 oct 2012

Not quite sure what you mean on 2nd point.

Not quite sure what you mean on point 2 but happy to be stepped through process. Im on Lync & could share desktop if you wanted.

In the meantime what do I need to do to fix this issue.

I don’t want to have to rebuild these 4 cloud services.

Thanks

Todd

From: davidjrh [email removed]
Sent: Wednesday, 6 March 2013 10:01 AM
To: Todd Lane
Subject: Re: Startup tasks [dnnazureaccelerator:435387]

From: davidjrh

Good catch @tango,

I have added the EXIT /B 0 in the three startup tasks (in fact is a good practice). The redirection for the stdout and stderr were there for debugging the execution result, but was missing to "hide" the ERRORLEVEL on exit. I have done the changes and checked-in.

Don't know how this happened but I'm interested in to discover possible scenarios. Can you tell me:

  • Which package and version are you using? (I'm supposing a minimum of 6.3 but perhaps you have downloaded and build the latest version)
  • OSFamily? (I'm supposing you are using "2" depending on before)
  • Can you go to the WADLogsTable on Azure storage and look for activity just when this occured?

Thanks!!!

Coordinator
Mar 6, 2013 at 5:55 PM
Hi @Tango,

the best approach for fixing this would be to get the changeset 18664 (the one associated with the 6.3 release), apply the patch and rebuild the package, something that at this point I would hate to do just now because I would need to downgrade my development environment to the Azure SDK 1.7 just when I'm finishing a new release including lot of new features including this fix.

I'm thinking on a workaround modifying directly the compiled package and if it works, I will share the link here to download. Note that the only thing you will need to do is just to redeploy the cloud service by using the same service configuration file you used for each one, no SQL data or DNN data will be erased. The redeployment will take around 10-15 mins to complete.

I'm going to change the most commonly used DNNAzureSingleAndSmall_6_3_RDP.cspkg package. Can you confirm me this was the package you used?
Mar 6, 2013 at 7:39 PM
Yes

Single and small

Thanks David

From: davidjrh <notifications@codeplex.com>
Reply-To: "dnnazureaccelerator@discussions.codeplex.com" <dnnazureaccelerator@discussions.codeplex.com>
Date: Thursday, 7 March 2013 5:59 AM
To: Todd Lane <Todd.Lane@utiliseit.com.au>
Subject: Re: Startup tasks [dnnazureaccelerator:435387]

From: davidjrh

Hi @Tango,

the best approach for fixing this would be to get the changeset 18664 (the one associated with the 6.3 release), apply the patch and rebuild the package, something that at this point I would hate to do just now because I would need to downgrade my development environment to the Azure SDK 1.7 just when I'm finishing a new release including lot of new features including this fix.

I'm thinking on a workaround modifying directly the compiled package and if it works, I will share the link here to download. Note that the only thing you will need to do is just to redeploy the cloud service by using the same service configuration file you used for each one, no SQL data or DNN data will be erased. The redeployment will take around 10-15 mins to complete.

I'm going to change the most commonly used DNNAzureSingleAndSmall_6_3_RDP.cspkg package. Can you confirm me this was the package you used?
Coordinator
Mar 6, 2013 at 9:07 PM
Hi @tango,

I have tried to workaround the issue by manually building the package with no success. My actual recommendation is that if you are not using WebDeploy go and disable it by changing these settings on the cloud service settings:
  <Setting name="WebPlatformInstaller.Products" value="" />
  <Setting name="WebPlatformInstaller.Enabled" value="false" />
  <Setting name="IISRemoteManagement.Enabled" value="false" />
You can do that:
  • by redeploying again with these settings,
  • or just by going and change those values on the running cloud services, ensuring that on another rollup upgrade the new instance will use the running setting values.
I will accelerate the process of building the next release. Sorry for any inconvenience.

David