Forum Discussion

JDL_53476's avatar
JDL_53476
Icon for Nimbostratus rankNimbostratus
Feb 10, 2015
Solved

SharePoint 2013 Office Web Apps and APM

I'm having an issue with SharePoint 2013 Office Web Apps (OWA) going through APM. When I first try to open a document, I get the error: "Sorry, there was a problem and we can't open this document. If this happens again, try opening the document in Microsoft Word." If I then hit the refresh button, it opens right up and every other OWA works like a charm. It is the first one of the session that bombs out. Any ideas or a workaround or why this is happening?

 

More info: In order for it to work at all I had to write an irule looking for User-Agent "MSWAC" and disable APM. The OWA server is a separate virtual server from the rest of the SharePoint sites.

 

Thanks

 

BIG-IP Access Policy Manager (APM)
deployment
microsoft
security
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Feb 10, 2015

    Hi JDL, if you want to protect Web Apps with APM, you need to colocate it with the SharePoint virtual server and make sure the Web Apps FQDN is included in the list when you deploy the iApp (that will add it to the multi-domains list in the APM profile). If you are doing a separate virtual server, it shouldn't have an APM policy assigned.

     

5 Replies

Sort By
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Feb 10, 2015

    Hi JDL, if you want to protect Web Apps with APM, you need to colocate it with the SharePoint virtual server and make sure the Web Apps FQDN is included in the list when you deploy the iApp (that will add it to the multi-domains list in the APM profile). If you are doing a separate virtual server, it shouldn't have an APM policy assigned.

     

  • JDL_53476's avatar
    JDL_53476
    Icon for Nimbostratus rankNimbostratus
    Feb 10, 2015

    Yeah I looked over the OWA deployment guide and saw that it doesn't even have an APM policy section except in reference to the other servers so once I removed it, everything worked like a champ. Thanks!

     

  • denose_180085's avatar
    denose_180085
    Icon for Nimbostratus rankNimbostratus
    Nov 18, 2015

    Hi JDL, I am having this issue currently - 1 VS for SP and OWA 2013 which uses the iRule to assign the appropriate pool. With APM on, OWA fails unless I do an ACCESS::disable based on either User-Agent or IP. However, I still get the OWA error on the first preview/edit with OWA then every request after that it works. Any ideas? Thanks

     

  • JDL_53476's avatar
    JDL_53476
    Icon for Nimbostratus rankNimbostratus
    Nov 18, 2015

    Denose,

    That was basically the same issue that I was having and the only way I could consistently get the results I wanted was to have a separate VS for OWA and not assign it an APM policy. You may also be able to do within the irule used to assign the correct pool. For example:

    when HTTP_REQUEST {
  if { [HTTP::host] eq "owa.company.com" } {
     ACCESS::disable
     pool owa-pool
  } elseif { [HTTP::host] eq "sharepoint.company.com" } {
    pool sharepoint
  }
}

    I hope this helps.

  • denose_180085's avatar
    denose_180085
    Icon for Nimbostratus rankNimbostratus
    Nov 20, 2015

    Hi JDL, I am actually having issues with the OWA server when it calls sharepoint.company.com. Since it isn't a user it can't complete the SSO.

    What I was trying, which worked on every request after the first one:

    when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] contains "owa.company.com" } {
    pool OWA-pool
} else {
    if { [IP::addr [IP::client_addr] equals OWA-pool-member] } {
        ACCESS::disable
    }
    pool SP13-pool
    persist none
}
}

    It was as if it had to go through once to have ACCESS disabled and then it was right after that. I flipped the logic to be ACCESS::disable at the start and then enable for everything that isn't the OWA-pool-member, and this WORKS. Not sure that is good practice though.

    when HTTP_REQUEST {
ACCESS::disable
if { [string tolower [HTTP::host]] contains "owa.company.com" } {
    pool OWA-pool
} else {
    if { [IP::client_addr] != "OWA-pool-member" } {
        ACCESS::enable
    }
    pool SP13-pool
    persist none
}
}

    I'd probably rather have an iRule more like my first one that just disables when the OWA-pool-member hits SP but it doesn't work in its current form. I was thinking of adding a redirect back to the same URI after the ACCESS::disable (to simulate the second try, which works) but need an IF statement in there to check, IF ACCESS already been disabled once, don't redirect again.

    I might play with that some more, I was trying to use "ACCESS::session data get" but without success. I suppose I could set a cookie on the first pass and remove it if it exists on the second pass, just to prove my thinking.

    Cheers