Is it available multi task tag in <StartUp> or do I have to merge these cmd files to only one? - powershell

I am new Azure development and writing powershell script.
I want to run two cmd files for azure start up tasks. I added these files into solutions and set properties as "copy always".After I add new note into ServiceDefinition.csdef Here it is :
<Startup>
<Task commandLine="Startup\startupcmd.cmd > c:\logs\startuptasks.log" executionContext="elevated" taskType="background">
<Environment>
<Variable name="EMULATED">
<RoleInstanceValue xpath="/RoleEnvironment/Deployment/#emulated" />
</Variable>
</Environment>
</Task>
<Task commandLine="Startup\disableTimeout.cmd" executionContext="elevated" />
</Startup>
It's not deploying and getting this error : Instance 0 of role Web is busy
Now In my question : Is it available multi task tag in <StartUp> or do I have to merge these cmd files to only one ?

As per definition:
The Startup element describes a collection of tasks that run when the
role is started.
So yes, the answer to your concrete question is: Yes, you can define multiple startup tasks.
State Busy is almost fine, in terms it is bit better than cycling! What I would suggest it to enable Remote Desktop and connect to see what is going on with the start up task. Busy is set until all simple tasks have completed and returned 0 exit code. Your task may fail or may hang for a while and that's why you would see busy.

Related

Tool for explore and query ETW logs from Service Fabric on premise

I’m looking for a tool that will allow me to explore and query/search in logs from service fabric written in etl format. I tried to use MessageAnalyzer but it was loading long time and hangs, second tool windows logs explorer but after conversion to evtx logs looks like below and are useless for me:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-ServiceFabric" Guid="{cbd93bc2-71e5-4566-b3a7-595d8eeca6e8}" />
<EventID>65534</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>65534</Task>
<Opcode>254</Opcode>
<Keywords>0xffffffffffffff</Keywords>
<TimeCreated SystemTime="2018-08-17T14:11:30.484723000Z" />
<EventRecordID>11534</EventRecordID>
<Correlation />
<Execution ProcessID="14332" ThreadID="5124" ProcessorID="3" KernelTime="9" UserTime="63" />
<Channel />
<Computer>Machine Name</Computer>
<Security />
</System>
- <ProcessingErrorData>
<ErrorCode>15003</ErrorCode>
<DataItemName />
<EventPayload>0101005B69002C006F6E3D223022206C657..74656D706C6174653D22537461727441735072696D61727941726773222F3E0D0A20203C6576656E742076</EventPayload>
</ProcessingErrorData>
</Event>
I saw that on Azure (https://channel9.msdn.com/Events/dotnetConf/2018/S208 0 on 35 minute) there is option to use Application Insights to query result. Is there any tool that allow me to do this locally?
I generally use PerfView for most ETW Log analysis. It provides very good filter capabilities on the raw files without need to convert the logs to any format other format, also is very lightweight to process huge log files.
The Good side of using Tools like Log Analytics on OMS or Application Insights is that it provides advanced features like Alerting, Aggregation and SQL like queries on these same events. Also, after setup, you don't have to handle large log files(generally in the hosted on a Blob storage) to find logs for the application.
For Development, PerfView does the job, for production analysis I would recommend you go for OMS or AppInsights.
The only downside from LogAnalitics is that the events are not shown in real time, it takes a few minutes before you can see then in the portal, but is still faster than finding and copying the files for analysis on PerfView or other tools.

Set service Startup type in WiX installer

I am trying to set a pre-installed service's startup type to Automatic, using WiX. Another task was to start the service on install, which I achieved with:
<ServiceControl
Id="ServiceRunningState"
Name="[Service Name]"
Start="install"
Stop="install"
Wait="yes" />
Now I would also like to set the startup type. I have tried the following (see answer):
<ServiceConfig
Id="ServiceStartup"
ServiceName="[Service Name]"
DelayedAutoStart="yes"
OnInstall="yes"
OnReinstall="yes" />
But this didn't change the startup type of the service (tested from Manual startup type). And besides, I want the startup type to be Automatic, not Automatic (Delayed Start).
Please note that I am trying to modify an existing service, so there is no ServiceInstall element.
The two elements (ServiceControl and ServiceConfig) are children within a Component parent element.
Any help is appreciated :)
MSI doesn't support changing the startup type of a service that the package doesn't install. ServiceConfig doesn't let you get around that:
Applies only to installed auto-start services or services installed by this package with SERVICE_AUTO_START in the StartType field of the ServiceInstall table.
Solved by editing the registry via RegistryKey, see example:
<RegistryKey Root="HKLM"
Key="SYSTEM\CurrentControlSet\Services\[Service Name]"
Action="create">
<RegistryValue Type="integer" Name="Start" Value="2" />
<RegistryValue Type="integer" Name="DelayedAutostart" Value="0" />
</RegistryKey>
Note service may appear as Automatic (Delayed Start) in Services GUI. However, after restarting, Services GUI displayed the service startup type as Automatic.
Set the "DelayedAutoStart" parameter to "no", rather than "yes".

Windows Task Scheduler incorrectly spawns multiple instances per trigger (but need to be able to run multiple instances in parallel)

I have a task set to run an executable every 30 minutes via Windows Task Scheduler (OS: 64bit Windows Server Standard with SP2). This task needs to be able to run multiple instances of itself simultaneously, so this setting is selected: "If the task is already running, then the following rule applies: Run a new instance in parallel". (Reason: the task processes records in a queue table which may be empty or contain hundreds of thousands of records. Each task instance reserves a chunk of records to work on, so the instances won't collide)
The problem is, the task spawns multiple NEW instances at each trigger interval. It should only fire ONE NEW instance every 30 minutes. Often it spawns 2, 3, 4 or more new instances. At this point, the executable can handle the duplicate new instances without significant errors, but the server is doing more work than it needs to, and it just bugs me to no end that the task scheduler is misbehaving in this way. Here is what I have tried so far to fix:
Deleted and recreated the task (many times)
Rebooted the server
Installed this hotfix: http://support.microsoft.com/en-us/kb/2461249
Set to run every 30 minutes indefinitely
Set to run every 30 minutes daily, for duration of one day
Set "Synchronize across time zones" = true
Set "Run with highest privileges" = true
Set "Delay task for up to random delay of [X] seconds" = false (multiple new - instances are spawned all within the same second)
Set "Delay task for up to random delay of [30] seconds" = true (instead of firing during the same second, multiple new instances fire within a 30 second span)
Set "If the task fails, restart every 1 minute" = true
Set "If the task fails, restart every 1 minute" = false
Set "Run task as soon as possible after a scheduled start is missed" = false (if set to true, the problem is worse)
Even more puzzling: some other tasks on this server have the same or similar settings and do not have this problem. They had the problem before the hotfix, but after the hotfix it has been rare. Except for with this one task. What on earth could be the problem?
The exported task settings are below (with XXXX replacing sensitive info). I compared this point for point with another similar task that is not having the issue. The only differences: the working task has a different author, a different exe file, and runs every 5 minutes instead of every 30 minutes.
I'm about to chalk this up as a bug that Microsoft needs to fix some day, but thought I'd offer it up for review here before giving up.
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2014-08-27T10:09:33.7980839</Date>
<Author>XXXX\XXXX</Author>
<Description>Links newly downloaded images to products. Resizes and uploads different sizes to XXXX. Updates relevant tables. Logs errors.</Description>
</RegistrationInfo>
<Triggers>
<CalendarTrigger>
<Repetition>
<Interval>PT30M</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>false</StopAtDurationEnd>
</Repetition>
<StartBoundary>2015-02-11T19:06:00Z</StartBoundary>
<Enabled>true</Enabled>
<RandomDelay>PT30S</RandomDelay>
<ScheduleByDay>
<DaysInterval>1</DaysInterval>
</ScheduleByDay>
</CalendarTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>XXXX\XXXX</UserId>
<LogonType>Password</LogonType>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>true</WakeToRun>
<ExecutionTimeLimit>P1D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\XXXX\XXXX\XXXX.exe</Command>
</Exec>
</Actions>
</Task>
I was in the same boat, had one task firing off 3 times, and another firing off 9 times. but also a bunch that only fired once as expected. Problem persisted after installing the hotfix as well.
After all my research turned up no good leads, my next step was going to be opening a support case with Microsoft. Before doing so I figured I would try deleting and recreating the task now that I've installed the patch. I started by only deleting and recreating the trigger (which was set to run once a day) and setting it for a different time. Bingo, my problem was fixed!
So I don't know what the key was, whether it was deleting and recreating the trigger after the patch was installed or if it was changing the time, but doing both worked.
Hope this helps!

CruiseControl.NET no connection can be made?

I am setting up CruiseControl.NET and I get the following error message on the webdashboard:
No connection could be made because the target machine actively refused it 127.0.0.1:21234
The Url it is looking for is: tcp://localhost:21234/CruiseManager.rem
However the ccnet website in IIS has its tcp port set to 82.
So I use the following Url to navigate to the webdashboard http://127.0.0.1:82/ccnet/ViewFarmReport.aspx
I tried changing the Tcp port in IIS to 21234 and I get the following error message on the webdashboard:
Tcp channel protocol violation: expecting preamble.
I have also tried opening the port with the following command:
netsh firewall add portopening TCP 21234 CCNET
When I try and start the CCNET service I get the following message
The CruiseControl.NET Server service started then stopped. Some services stop automatically if they have no work to do....
Can anyone help me with this problem please?
EDIT - Adding config file
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:define PublishDir="C:\Deploy\Portal2.0Build"/>
<project name="Portal2.0">
<workingDirectory>C:\PortalCruiseControl\Working</workingDirectory>
<artifactDirectory>C:\PortalCruiseControl\Artifacts</artifactDirectory>
<webURL>http://192.168.17.59:82/ccnet</webURL>
<triggers>
<intervalTrigger name="continuous" seconds="10"
buildCondition="IfModificationExists"/>
</triggers>
<sourcecontrol type="svn">
<trunkUrl>https://portal2003.local:8443/svn/portalv2.0/trunk</trunkUrl>
<executable>C:\Program Files (x86)\VisualSVN Server\bin\svn.exe</executable>
<username>ccnet</username>
<password>***</password>
<cleanCopy>true</cleanCopy>
</sourcecontrol>
<tasks>
<msbuild>
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
<projectFile>Portal2.0.sln</projectFile>
<buildArgs>
/target:build;publish /p:Configuration=Release /p:MSBuildExtensionsPath=C:\Progra~2\MSBuild /p:MSBuildEmitSolution=1 /p:publishdir=C:\Deploy\Portal2.0Build /verbosity:diag
</buildArgs>
<logger>
C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll
</logger>
</msbuild>
</tasks>
<labeller type="assemblyVersionLabeller">
<major>2</major>
<minor>0</minor>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
<publishers>
<statistics />
<xmllogger />
<package>
<name>ZipFilePublish</name>
<compression>9</compression>
<always>false</always>
<flatten>false</flatten>
<baseDirectory>$(PublishDir)</baseDirectory>
<dynamicValues>
<replacementValue property="name">
<format>C:\Deploy\Builds\PortalBuild{0}.zip</format>
<parameters>
<namedValue name="$CCNetLabel" value="Default" />
</parameters>
</replacementValue>
</dynamicValues>
<files>
<file>*.*</file>
<file>**\*</file>
</files>
</package>
<email from="bla" mailhost="bla" port="25" userName="bla"
password="bla" includeDetails="TRUE" useSSL="FALSE">
<users>
<user name="User1" group="Portal" address=""/>
</users>
<groups>
<group name="Portal">
<notifications>
<notificationType>change</notificationType>
</notifications>
</group>
</groups>
</email>
</publishers>
</project>
The first error message is probably caused by CCNET service not running because of which the web dashboard can't connect to it. It should go away as soon as you fix the ccnet.config so that service starts running.
The second problem ("Ilegal characters in path"; you seem to have already figured out the missing nodes part) is caused by msbuild/executable element. It seems that CC.NET doesn't like whitespace and especially new line characters inside it's value. Replacing:
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
with:
<executable>C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe</executable>
should fix the problem.
Another hint: when you're having problems with the validity of your ccnet.config file, try using CCValidator.exe (it's in your CruiseControl.NET\server folder). It usually points out the problematic part of the config file quite nicely (although that wasn't the case with "Illegal characters in path" problem - I had to comment out specific parts of the config to find the offending node).
The first message you receive (connection actively refused) makes me think of a firewall which is blocking the port you're using.
The second problem could be anything. It could for instance be an error in your XML configuration (ccnet.config) file. Can you find any pointers in the Windows Eventlog ?
Regarding the 2nd problem: did you try to run the CC.NET server from the command line?
If you've got an error in your XML configuration, this will give you a more meaningful error message.
Which account are you using to run the Windows service?
Have you checked your ccnet's dashboard.config file?
It has the following line in it:
<server name="local" url="tcp://localhost:21234/CruiseManager.rem" ... />
Try changing the port on that to 82 and then restarting the website (you should be just able to add a space to the web.config file and save and IIS will restart the website).
Sounds like you're confusing two different functions:
tcp://localhost:21234
This is the default remoting port for clients like CCTray. This is not used for the IIS web site (dashboard).
Configuration document is likely missing Xml nodes required for properly populating CruiseControl co nfiguration. Missing Xml node (packageList) for required member (ThoughtWorks.CruiseControl.Core.Publishers.Package Publisher.PackageList)
Your example config is missing required packageList node.
A misleading error message. The port really is 21234, not 82. I got the same errors. The fix was to start ccnet.exe from the desktop shortcut to discover that the real problem was illegal code in my ccnet.config file.
After fixing the ccnet.config file, the problem moved on. When attempting to build, the system would not let the subversion client modify the read-only marker files in the checked out repo.
In my case I misprinted project configuration file name in ccnet.config instead of timescheduler.config it were timesheduler. When I fixed file name I was able to run ccnet service.
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:include href="definitions.xml" xmlns:cb="urn:ccnet.config.builder"/>
<cb:include href="projects/timescheduler.config" xmlns:cb="urn:ccnet.config.builder"/>
</cruisecontrol>

NServiceBus pipeline with Distributors

I'm building a processing pipeline with NServiceBus but I'm having trouble with the configuration of the distributors in order to make each step in the process scalable. Here's some info:
The pipeline will have a master process that says "OK, time to start" for a WorkItem, which will then start a process like a flowchart.
Each step in the flowchart may be computationally expensive, so I want the ability to scale out each step. This tells me that each step needs a Distributor.
I want to be able to hook additional activities onto events later. This tells me I need to Publish() messages when it is done, not Send() them.
A process may need to branch based on a condition. This tells me that a process must be able to publish more than one type of message.
A process may need to join forks. I imagine I should use Sagas for this.
Hopefully these assumptions are good otherwise I'm in more trouble than I thought.
For the sake of simplicity, let's forget about forking or joining and consider a simple pipeline, with Step A followed by Step B, and ending with Step C. Each step gets its own distributor and can have many nodes processing messages.
NodeA workers contain a IHandleMessages processor, and publish EventA
NodeB workers contain a IHandleMessages processor, and publish Event B
NodeC workers contain a IHandleMessages processor, and then the pipeline is complete.
Here are the relevant parts of the config files, where # denotes the number of the worker, (i.e. there are input queues NodeA.1 and NodeA.2):
NodeA:
<MsmqTransportConfig InputQueue="NodeA.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeA.Distrib.Control" DistributorDataAddress="NodeA.Distrib.Data" >
<MessageEndpointMappings>
</MessageEndpointMappings>
</UnicastBusConfig>
NodeB:
<MsmqTransportConfig InputQueue="NodeB.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeB.Distrib.Control" DistributorDataAddress="NodeB.Distrib.Data" >
<MessageEndpointMappings>
<add Messages="Messages.EventA, Messages" Endpoint="NodeA.Distrib.Data" />
</MessageEndpointMappings>
</UnicastBusConfig>
NodeC:
<MsmqTransportConfig InputQueue="NodeC.#" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress="NodeC.Distrib.Control" DistributorDataAddress="NodeC.Distrib.Data" >
<MessageEndpointMappings>
<add Messages="Messages.EventB, Messages" Endpoint="NodeB.Distrib.Data" />
</MessageEndpointMappings>
</UnicastBusConfig>
And here are the relevant parts of the distributor configs:
Distributor A:
<add key="DataInputQueue" value="NodeA.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeA.Distrib.Control"/>
<add key="StorageQueue" value="NodeA.Distrib.Storage"/>
Distributor B:
<add key="DataInputQueue" value="NodeB.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeB.Distrib.Control"/>
<add key="StorageQueue" value="NodeB.Distrib.Storage"/>
Distributor C:
<add key="DataInputQueue" value="NodeC.Distrib.Data"/>
<add key="ControlInputQueue" value="NodeC.Distrib.Control"/>
<add key="StorageQueue" value="NodeC.Distrib.Storage"/>
I'm testing using 2 instances of each node, and the problem seems to come up in the middle at Node B. There are basically 2 things that might happen:
Both instances of Node B report that it is subscribing to EventA, and also that NodeC.Distrib.Data#MYCOMPUTER is subscribing to the EventB that Node B publishes. In this case, everything works great.
Both instances of Node B report that it is subscribing to EventA, however, one worker says NodeC.Distrib.Data#MYCOMPUTER is subscribing TWICE, while the other worker does not mention it.
In the second case, which seem to be controlled only by the way the distributor routes the subscription messages, if the "overachiever" node processes an EventA, all is well. If the "underachiever" processes EventA, then the publish of EventB has no subscribers and the workflow dies.
So, my questions:
Is this kind of setup possible?
Is the configuration correct? It's hard to find any examples of configuration with distributors beyond a simple one-level publisher/2-worker setup.
Would it make more sense to have one central broker process that does all the non-computationally-intensive traffic cop operations, and only sends messages to processes behind distributors when the task is long-running and must be load balanced?
Then the load-balanced nodes could simply reply back to the central broker, which seems easier.
On the other hand, that seems at odds with the decentralization that is NServiceBus's strength.
And if this is the answer, and the long running process's done event is a reply, how do you keep the Publish that enables later extensibility on published events?
The problem you have is that your nodes don't see each others list of subscribers. The reason you're having that problem is that your trying out a production scenario (scale-out) under the default NServiceBus profile (lite) which doesn't support scale-out but makes single-machine development very productive.
To solve the problem, run the NServiceBus host using the production profile as described on this page:
http://docs.particular.net/nservicebus/hosting/nservicebus-host/profiles
That will let different nodes share the same list of subscribers.
Other than that, your configuration is right on.