As announced in the release notes, PPM Pro will be changing domain names to align the domain name with the product branding. URLs currently using innotas.com will use ppmpro.com.
The domain name change has happened and now my browser isn't filling in my saved password.
This is because the browser is seeing the new domain name as a different site. If you enter your password one time it will be remembered. If you forgot your password, you can recover it as described below:
- Go to the 3 dots in the upper right corner of the screen.
- Click on Passwords under Autofill
- Find the correct innotas.com website login and click on the eye icon to view the password. You'll need to sign in using your machine credentials (Windows login), but then your password should be visible.
- Go to Settings (gear icon) > Internet Options
- Go to the Content tab, and select the AutoComplete Settings button.
- Click the Manage Passwords button.
- Click the down arrow to expand the appropriate innotas.com login credential
- Click Show next to the Password.It should ask for your Windows credentials and then show you the password.
- Click on the menu button to open the menu panel.
- Click Logins and Passwords. A window will open with a list of your saved logins.
- Search or scroll to find the login you want to change.
- Usernames: Double-click the username to change it.
- Passwords: Click Show Passwords. Double-click the password to change it.
When is the change taking place?
The domain name changeover will take place with the October release. Sandboxes will be updated first, on October 11 during the usual regional maintenance windows. Production instances will be updated on October 25th during the maintenance windows. No service disruption is expected outside the normal maintenance window.
What do I need to do now?
Most likely, nothing. Some organizations have strict firewall or email rules in place which whilelist certain sites. If your organization has whitelisted innotas.com or email@example.com you should add a whitelist entry for ppmpro.com and/or firstname.lastname@example.org now so you’ll be ready (leave the existing whitelists in place as well until after the transition has taken place).
What will I need to do later?
When convenient, you can:
- update any links to PPM Pro, including published dashboards (intranet sites, sharepoint, documentation, and so on). Again, we'll have redirects in place so existing links to innotas.com will continue to work but it would be the least confusing if links from these sites are updated to use ppmpro.com
- change any integrations not managed by Planview to use ppmpro.com (redirects will be in place to give you time to do this)
- update any SSO configuration. Currently, we use innotas.com as the SAML issuer ID. There's no requirement that this match the URLs being used but it's less confusing to administrators if it does. Contact customer care to help plan your SSO updates.
How will the redirects work?
Any requests to https://*.innotas.com/* will be redirected by an HTTP 307 response to the matching URL at ppmpro.com. This will cover SSO, published dashboards, links from email alerts, and so forth.
How long will the redirects remain in place?
No specific timetable has been put in place for removing the redirects at this time. The redirects will remain for at least a year, and likely much longer. After a year, we’ll monitor how much the redirects are still being used and provide further communication. Our hope is that all users will migrate fully to ppmpro.com in a good time but there’s no need to rush.
Why are you using HTTP 307? Will it work with all browsers?
HTTP 307 was added with HTTP/1.1 in 1999. It specifies that clients should redirect any method, including POST. Most clients will convert POSTs to GETs when responding to the older HTTP 302-style redirects. This is particularly important to SAML requests which come in as POSTs.
All modern browsers support HTTP 307. We’ve tested with all of our supported browsers (current versions of Chrome and Firefox as well as Internet Explorer 11) and all support this correctly. It is possible that very old versions of browsers will not support it.
What testing has been done?
Prior to rolling this out, we have set up an alternate set of top-level domains so we could match production as closely as possible. Testing has been done, including:
- All supported browsers (Chrome, Firefox, IE 11)
- Published dashboards
- Email alert links
- WSAPI/SOAP endpoints with SoapUI, Boomi, and SnapLogic
We have not tested older versions of browsers nor is it possible to test all SOAP API clients.
Will my integrations still work?
The redirects should keep all integrations working until you have the chance to re-configure them to use ppmpro.com.
If you would like to confirm that your custom integration client will properly follow redirects, there are a couple of options available:
- test the integration in your sandbox after the sandbox release on the night of October 11 -- we recommend you do this as soon as possible after the sandbox release
- we have an "API test bed" available. Point your SOAP client to https://apitest.innotas.com/services...oap11Endpoint/ and send a SOAP request, such as:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services">
If you get a SOAP response like the following, your client successfully followed the redirects (you will get an authentication fault in the successful case since the username and password is not valid, but if it's a SOAP error rather than a network or client error, the test was successful):
<faultstring>Unable to authenticate user. Incorrect target server</faultstring>
If you're looking at the network traffic, you should see the following:
- a POST request to https://apitest.innotas.com/services...oap11Endpoint/
- a response with an HTTP 307 and Location header "https://apitest.ppmpro.com/services/...oap11Endpoint/"
- a POST request to https://apitest.ppmpro.com/services/...oap11Endpoint/
- a response with an HTTP 500 and the SOAP error message referenced above.
Here's an example using curl:
$ curl -iL -d "@request.xml" -H "Content-Type: text/xml;charset=UTF-8" -H "SOAPAction:urn:login" -X POST https://apitest.innotas.com/services...oap11Endpoint/
date: Sat, 05 Oct 2019 19:28:25 GMT
server: nginx/1.14.0 (Ubuntu)
HTTP/1.1 500 500
Date: Sat, 05 Oct 2019 19:28:26 GMT
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header /><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server</faultcode><faultstring>Incorrect username and/or password. Contact your help desk or your organization's internal PPM Pro Administrator for help with your userid or password.</faultstring><detail /></soapenv:Fault></soapenv:Body></soapenv:Envelope>
If you run into issues or have questions, please contact customer care. While customer care is not able to provide coding help with custom integrations, we can provide general help with general questions about the testing process and the transition.