Question Status

Verified
Volker Deuss asked a question on 15 Feb 2012 2:18 AM

Hi everyone!

I'm trying to get RapidStart Services to work with my AX 2012 (development) installation. Registration on PartnerSource worked fine; installation of the RapidStart Connector Service, too.

Now I am able to start the RapidStart Connector Service in Windows Services (local), although it is stopped after startup because it is not used by other programs or services.

Obviously, the RapidStart Connector Service is meant to be started by the small configuration program installed with it, after clicking on "Activate" or "Start service". Unfortunately this doesn't work in my case (though the >visible< setup is correct). After 30s an exception is thrown and shown telling that there was a timeout and therefore the startup process of the service gets terminated.

The needed inbound ports are activated (AifGDS and AppConfigServices), those default timeout settings in nettcpbindings should be fine. RapidStart Services Connector itself also has timeout settings, defined in xml configuration files you can find  in the installation path. They look fine, too.

I'm wondering about the 30s especially because there's no 30s timeout setting anywhere...

Any suggestions would be appreciated.

Reply
Volker Deuss responded on 16 Feb 2012 1:22 AM

Hmm, did anyone of you use RapidStart Services before? Maybe you could tell me how long the startup of "RapidStart Connector Service" takes. Maybe there's an infrastructural problem here and the service should be up and running way faster...

Reply
Volker Deuss responded on 17 Feb 2012 8:08 AM

I have some news :) The problem is caused by our company's network. Communication like this is only allowed through a proxy here. RapidStart Services Connector doesn't seem to be able to handle this. Unfortunately I won't be able to keep the exceptions we made in our environment for getting this to work. And thinking of customer environments certainly underlines the need for RapidStart to be able to handle proxies.

Maybe one of you is able to give me a hint about a possible solution. I think RapidStart Services should be able to function in such environments.

Reply
Jason Lee [MYS] responded on 8 Mar 2012 2:53 AM

Hi Volker, a bit of a side track to your topic. am actually having an issue with loading the default configuration data into my target application. have you managed to try that out before on your end and is successful all the way until you see the sample company data in AX, ready to create transactions and post them immediately after the import? am referring to the way that way depicted on one of the videos.

Reply
Volker Deuss responded on 8 Mar 2012 3:46 AM

Hi Jason, I'll answer this one in the thread you created (community.dynamics.com/.../74792.aspx).

Reply
Landon Frenzel responded on 12 Mar 2012 3:56 PM

I was having this same issue when trying to configure an AX install on a VM image.  I had my network settings set to NAT.  Switching to bridged and rebooting resolved all issues.  I was able to get the connector activated and the service started without a problem after that.

Reply
Verified Answer
Volker Deuss responded on 14 Mar 2012 1:29 AM

Well, I think you can have that issue only if you use VMware ;)

In this case I'm using Hyper-V and an "external" network. With Hyper-V you don't have that choice about NAT or bridged. Maybe this will be helpful for others anyway, thank you.

Meanwhile, I (or we, I had a little help from a Microsoft guy) discovered that right now there's no other way than opening those ports (9350 to 9354). This is also said on msdn (msdn.microsoft.com/.../ee706729.aspx).

The error you find in the event log should be something like "Chunked encoding upload is not supported on the HTTP/1.0 protocol". That led me to this blog entry (see pitfall 4): blog.jayway.com/.../windows-azure-servicebus-pitfalls

This one points to another blog entry on msdn (blogs.msdn.com/.../additional-data-centers-for-windows-azure-platform-appfabric.aspx) where the ports are named and also ip ranges the service bus uses. Those ranges were not important in my case and the information there is one year old, but maybe someone might find this useful, too.

Regards

Volker

Reply
Jason Lee [MYS] responded on 14 Mar 2012 4:47 AM

Hi Volker,

good to hear that you got your side working already.

My setup is really similar as such that i am also using Hyper-V to host my server image where i am setting all this up. So you are saying after configuring your office firewall to open to ports (9350 to 9354) that it already works?

I asked my network team to do the same, but still am facing the same dreaded issue...

what figures? anything that i might have missed out?

Best regards,

Jason Lee

Reply
Volker Deuss responded on 14 Mar 2012 5:00 AM

My description only solves the problem with the startup of the RapidStart Connector process I discovered first. I still had that "Validating loader lock status".

But yesterday I passed this one with a whole new installation, too! Right now I'm trying to find out what made the difference. Of course I'll let you know then (in that thread of yours).

Reply
Georg Braun responded on 31 May 2012 1:41 AM

Hi guys,

I have done all the required setup for the Rapid Start Service on the online-plattform and our AX Home Server.

When I try to start the Rapid-Start-Connerctor-Service I get the following message:

Unable to start serbice System.ServiceProcess.TimoutException:

Time out has expired and the operation has not been completed.

at

system.serviceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)

at

AppConfig.ConnectorLoaderServiceConnectionPage.MainForm.StartService()

As I have read from one post, it could be the OpenTimeout setting on the service but have no idea where to set this property.

Does anybody have the same issue or have any idea how to solve it?

Thank you in advance!

With best Regards,

Georg

Reply
Volker Deuss responded on 31 May 2012 2:18 AM

Hi Georg,

does the service start anyway? I'm sometimes experiencing that it RSConnector throws that error although the service still is in startup phase. Then you could just ignore the timeout message (I do so and it works fine).

If the service doesn't start you should check/open ports 9350 to 9354 (all firewalls between the AOS [I guess RSConnector is installed there as suggested by Microsoft] and the internet).

Regards.

Reply
Georg Braun responded on 1 Jun 2012 12:39 AM

Hi Volker,

great news!

Your instruction was very helpful. We have opened the ports as you have suggested and the service (RSConnector) began to run.

Thank you very much for your help!

I really appreciate to get hints and help from you experts.

Thanks and best Regards,

Georg

Reply
Georg Braun responded on 5 Jun 2012 11:03 AM

Dear coleagues,

unfortunately I can not load my project from the Rapid-Start-Service to AX due to an internal Error @MS.

I think the problem could be my Service Setup.

My Server-Location is in Germany and I use a Test-Customer with German country settings.

Does anyone have experience with setting up this Service for Germany?

The Setup looks like this:

Many thanks for your help.

With best Regards,

Georg

Reply
Verified Answer
Volker Deuss responded on 14 Mar 2012 1:29 AM

Well, I think you can have that issue only if you use VMware ;)

In this case I'm using Hyper-V and an "external" network. With Hyper-V you don't have that choice about NAT or bridged. Maybe this will be helpful for others anyway, thank you.

Meanwhile, I (or we, I had a little help from a Microsoft guy) discovered that right now there's no other way than opening those ports (9350 to 9354). This is also said on msdn (msdn.microsoft.com/.../ee706729.aspx).

The error you find in the event log should be something like "Chunked encoding upload is not supported on the HTTP/1.0 protocol". That led me to this blog entry (see pitfall 4): blog.jayway.com/.../windows-azure-servicebus-pitfalls

This one points to another blog entry on msdn (blogs.msdn.com/.../additional-data-centers-for-windows-azure-platform-appfabric.aspx) where the ports are named and also ip ranges the service bus uses. Those ranges were not important in my case and the information there is one year old, but maybe someone might find this useful, too.

Regards

Volker

Reply