I'm trying to get things working with the ZuluSampleData file. I've installed the servlet, paired the ZuluSampleData file with a google account, and ran Sync Now, which completed successfully.

I understand the next step to be to click the 'Publish' button in the hosted ZuluSampleData file. When I do this, a web page opens up and I get an 'Authentication Required' message which looks like a sort of dialog window but it's contained within the browser (I'm using Chrome). The message says: "The server 10.0.x.x:80 requires a username and password." What account should I be using here?

The instructions in step 3 in the ServeTheSampleFile documentation page say: You'll be asked for the file's account name and password, enter "Zulu" (without quotes) for both.

But this doesn't work for me. I've also tried Admin with a blank password, and I've tried the account that I set up to administer Zulu with (at localhost/zulu/admin). Each time, when I click on the Log In button, the dialog window comes right back, indicating that it didn't work.

Not knowing what else to try, I tried logging in with my windows login (thinking that maybe this was the web server asking me to authenticate, and that somehow my windows credentials would...I don't know, do something) and also with my FileMaker Server admin account. Strangely, for both of these, the authentication dialog window does go away, but then I'm directed to a page with the following text:

Calendar Publishing Error
com.prosc.servlet.UnsupportedAuthenticationException: Only basic authentication is supported. Received this authentication header: (Negotiate............... (and so on)

I'm using the demo version of Zulu v1.316, FileMaker Server 11 Advanced, Windows Server 2003 SP2.

Help please.

Hi,

Hope all is well.

mkos wrote:I understand the next step to be to click the 'Publish' button in the hosted ZuluSampleData file. When I do this, a web page opens up and I get an 'Authentication Required' message which looks like a sort of dialog window but it's contained within the browser. The message says: "The server 10.0.x.x:80 requires a username and password." What account should I be using here?

The instructions in step 3 in the ServeTheSampleFile documentation page say: You'll be asked for the file's account name and password, enter "Zulu" (without quotes) for both.

But this doesn't work for me. I've also tried Admin with a blank password, and I've tried the account that I set up to administer Zulu with (at localhost/zulu/admin). Each time, when I click on the Log In button, the dialog window comes right back, indicating that it didn't work.

This is an account and password for the file you're publishing from. Zulu / Zulu is the account that's set-up in the sample file, so you'll just want to use an account for your file. Preferably a [Full Access] account, and a password is required. All publishing does is to create the initial ZuluCalendarList record. It does so via CWP/XML so needs the access for the file itself.

Thanks!

All I'm doing for right now is trying to get the ZuluSampleData file working with a google calendar that I have set up. So, the file I'm publishing from is ZuluSampleData. The two accounts there are admin (password is blank) and Zulu (password is also Zulu). I've tried both of these, but neither one works.

Sorry, I misunderstood.

If you're running in demo mode, then the Web Publishing Engine needs to be restarted every two hours, so that could be the cause. I think that's it, as since your getting asked for credentials, then Zulu's able to communicate with FileMaker Server. Cycle the WPE and give it another try,

Otherwise, we have some troubleshooting steps here under the "Is It Your Server" section for testing and correcting the connectivity between Zulu and FMS.

Let me know if that helps!

I tried restarting WPE, and that didn't fix it.

I've switched my server's default browser from Chrome to IE in the meantime. The authentication dialog window now looks different. When I try to authenticate using "Zulu" for both user name and password, the dialog window replaces "Zulu" in the user name field with "10.0.1.x\Zulu". Is this authentication dialog window really the one that is asking for my FileMaker file credentials? It looks more like something I'd see from the web server.

I've also read through the Troubleshooting page in the Zulu Documentation. It seems to assume that I will be using Zulu with iCal, which I won't; my purpose is to use it to sync with a Google Calendar only. I'm guessing this is not a problem, but I'm mentioning it here just in case it is.

Also, in the Troubleshooting page, there's this bullet point:

• Make sure each of your ZuluCalendarList records has a unique zulu_uuid. This field can not be blank for any of these calendar records.

The ZuluSampleData file came with zero ZuluCalendarList records. I think I read somewhere else in the documentation that the Publish Calendar action is supposed to create one of these. Should I create it manually instead?

Any other ideas or suggestions?

Hi,

mkos wrote:I've switched my server's default browser from Chrome to IE in the meantime. The authentication dialog window now looks different. When I try to authenticate using "Zulu" for both user name and password, the dialog window replaces "Zulu" in the user name field with "10.0.1.x\Zulu". Is this authentication dialog window really the one that is asking for my FileMaker file credentials? It looks more like something I'd see from the web server.

Thanks for that info. It's certainly possible some other service is intercepting or stopping this request to FileMaker Server via port 80. The dbnames test in the troubleshooting section is what I'd try next. Whether it's iCal or Google Sync, Zulu uses XML/CWP to communicate with with the FileMaker server, and it seems like that could be the problem. Is anything else going on with this server? The URL that lets you hit the XML Web Publishing is what you'll want to use for publishing. By default it uses Get ( HostIPAddress ), but that may need to be overridden.

You could try and publish from the same machine that the server's on if you have an FM client there, and maybe that will get around this authentication problem. If you're just planning on using the Google Sync, this may work as The Server talks directly to Google, however, proxies are not supported and 2 way authentication is required for Zulu to talk to Google.

JasonYoung wrote:The ZuluSampleData file came with zero ZuluCalendarList records. I think I read somewhere else in the documentation that the Publish Calendar action is supposed to create one of these. Should I create it manually instead?

No, the publish script tracks the field mapping that's set up and encodes that in the ZuluCalendarList record, so that step is required. We also use that to identify if there's an issue communicating with Zulu and or the server via XML early in the process as that will most likely cause other issues.

Let us know if that helps.
-Jason

The dbnames test in the troubleshooting section is what I'd try next.

I entered this into my browser:

http://10.0.1.x/fmi/xml/FMPXMLRESULT.xml?-dbnames

and I can confirm that this URL does indeed return XML and ZuluSampleData is among the files listed.

The URL that lets you hit the XML Web Publishing is what you'll want to use for publishing.

I don't follow. Am I suppose to specify a URL somewhere? Or do you mean that the URL that is opened when I click on the Publish button in the ZuluSampleData file should be using the same IP as the one I used in the dbnames test. (It does.)

By default it uses Get ( HostIPAddress ), but that may need to be overridden.

I can confirm that when I view Get ( HostIPAddress ) in the Data Viewer with the ZuluSampleData file open, the value returned is the same 10.0.1.x IP as above.

You could try and publish from the same machine that the server's on if you have an FM client there

Yup, that's where I've been doing all this from.

Any other ideas?

Thanks for the details.

The dbnames test is for doing two things. To test if localhost works from the server, and if not, what address does work. Zulu uses "localhost" by default, but this can be changed by updating the zulu.XML file. If localhost does not work, but 10.0.1.x does, then it could just be a matter of changing the localhost reference in the zulu.XML file to the actual IP.

mkos wrote:I don't follow. Am I suppose to specify a URL somewhere? Or do you mean that the URL that is opened when I click on the Publish button in the ZuluSampleData file should be using the same IP as the one I used in the dbnames test. (It does.)

If the 10.0.1.x did not work, then this would be the case. This is typically if the web server is at a different address then the FMS, but that's not the case here.

Since the dbnames test with the 10. address worked without triggering an authentication request, then hopefully telling Zulu to use that address instead of localhost will resolve the issue. It does seem like the Web Server is asking for authentication that Zulu doesn't have control over. It may be that satisfying those credentials will then allow Zulu will try to authenticate to the FMS/XML with the file account and password. Otherwise that additional authentication may need to be disabled.

Hope that Helps,
-Jason

I replaced localhost with the 10. address in the zulu.xml config file. I also rebooted the server machine.

Still not working.

Not sure what else to try.

I've uploaded a video showing what's happening:

http://www.youtube.com/watch?v=M33uFQVlVfI

Is the authentication prompt shown in this video what you expect to see when trying to publish a calendar?

Step three in the ServeTheSampleFile instructions (http://www.seedcode.com/pmwiki/pmwiki.php?n=Zulu.ServeTheSampleFile) say: "You'll be asked for the file's account name and password, enter "Zulu" (without quotes) for both."

But this video http://www.youtube.com/watch?v=t5sA8bMmmcE (at the 2:46 mark) doesn't show any authentication being done.

In my video, you can see how trying to login w Zulu/Zulu doesn't work.

You can also see what happens in my video at 0:39 when I try to use the local windows user account. It seems to accept the credentials, but then I'm taken to some error page.

FYI: The video is an unlisted, and I plan on removing it after you've had a chance to view it.

Thanks.

I got it to work by disabling "Integrated Windows authentication" in the IIS setup.

• Open Programs > Administrative Tools > IIS Manager
• Right-click on the default web site (or whatever web site you are using) and click Properties
• In the Directory Security tab, click on Edit within the Authentication and access control
• Uncheck "Integrated Windows authentication"

Previously, the "Enable anonymous access" and the "Integrated Windows authentication" checkboxes were enabled. I tried adding "Basic authentication" to the mix. And I tried it with only "Basic authentication"; i.e. disabling the other two.

This was the first time I tried it with only the "Enable anonymous access" setting enabled, and that worked.

Phew.

Two other things to point out.

1. I had to create the C:\Users\Public folders in order to get Zulu installed. These didn't exist for me to start with.

2. http://locahost/zulu didn't work for me. I had to add 127.0.0.1 to the IIS settings in order to get it to recognize localhost.

Here's how: Open IIS Manager, then right-click on the appropriate web site in the list on the left (for me this was 'Default Web Site'), then click Properties, then in the Web Site tab click on Advanced, then Add, enter in 127.0.0.1 as the IP and 80 as the TCP port.

I'm only mentioning these two here, because I installed Zulu on two servers, and I had to do these two things on both of those servers in order to get things to work, which means that this might not be altogether too uncommon.

Phew is right!

Thanks so much for posting all this info, I'm sure it will save somebody (me, most likely) some grief.

I haven't run into these IIS issues, but those can be tricky to track to track down, so again, thanks for the details there. I have had the Public Folder issue come up one or two times when FileMaker Server is installed on the D drive. I've asked the developer to look if this can be handled with the installation, and I'll tag that case with this one as well.

mkos wrote:2. http://locahost/zulu didn't work for me. I had to add 127.0.0.1 to the IIS settings in order to get it to recognize localhost.

Also, if localhost is disabled, you can change the default reference to it that Zulu uses to communicate with the Web Server in the zulu.XML file. Typically just replacing localhost with the actual IP of the Web Server.

Thanks again and please let us know if it gives you any more trouble.
-Jason