08-02-2019 12:30 AM
08-02-2019 12:30 AM
For enterprise a policy like the one in IE called "Go to an intranet site for a one-word entry in the Address bar" is very needed.
As an enterprise we have a lot of intranet sites and services using one-word hostnames and abreviations like "mc", "servicedesk" etc. that our users are used to just being able to type in their browser.
In Edge that will just launch a search on Google or Bing instead. Teaching the users to type http:// every time is nearly impossible and not very user friendly.
We use the policy in IE, but it sadly never came to Edge. It would be great if it could be added to the new Edge (Chromium) admx.
08-09-2019 11:59 AM - edited 08-09-2019 12:00 PM
@ToMMeR thank you for your feedback!
You are correct that Edge will perform a search on the single-word entry that omits the https:// prefix the first time, however once the user visits the intranet site, subsequent entries of the same text will auto-complete to the history entry and therefore perform a direct navigation to the intranet site.
I do hear your request for a policy to allow organizations to override the behavior I described and we are happy to consider that approach, however one thing that's important to note is that it will make it much more difficult for non-intranet, single-word query terms to be searched by users of any organization that enables such a policy should it be implemented.
Instead of conducting a search, all single-word queries would attempt to internally navigate and so any queries that don't match an intranet site would fail instead of search.
Please let us know if the current behavior which I described (relying on history entries for direct navigation to intranet sites), is sufficient for you, or if a policy is still important to you.
Thanks again for your feedback!
08-12-2019 10:38 PM - edited 08-12-2019 10:41 PM
@JaredB81 We also look forward for such a policy. Your suggestion is not suffiecient in our environment, as we delete all browser history on browser close, due to security reasons. Our users are anyway not allowed to use the Edge address bar for internet search.
But, it would be great to have the same behaviour as in MSIE. If the URL can be resolved internally, it forwards to intranet. If not, then a search engine shall be addressed.
08-12-2019 11:30 PM
@JaredB81 Thank you for your quick reply.
Although the auto-complete from the history navigating to the intranet site is a nice feature, it is not sufficient to satisfy our needs.
It is a big inconvenience if thousands of users have to learn to type in http://hostname or https://hostname the first time they visit each of the many intranet sites we have in our organisation.
It will cause many support cases to our service desk as our users does not understand why it doesn't work. Of course over time as the users visit each intranet site the problem decreases. But that is only until they get their pc reinstalled, get a new pc, get their history deleted etc. plus everytime we implement a new intranet site with a new hostname they have to do it all over for that website.
We have tried to get our users to use the current Edge version instead of IE on their pc's but many still use IE as their default simply because they get irritated that they cannot access our intranet sites without ending on Bing or Google.
We still need a Group Policy like the one that existed in Internet Explorer where we can choose if we want single word entries to go to intranet sites instead of doing a search.
In IE when typing a single word that does not resolve internally it does still fall back to a Bing/Google search, it just takes longer as it waits for the intranet request to time out before doing a Search.
08-13-2019 12:22 AM
@JaredB81- As the new Edge will replace and emulate IE for enterprises, it must respect the same GPO settings, including this one. Many enterprises use single-word names, for example, "intra" in our case.
Because it falls back to sending the word to the search engine if no host replies, it is not a problem, and something users have been used to for decades.
08-14-2019 01:47 PMSolution
We will look into adding a policy to make single-word queries navigate and I'll follow up on this thread with an update as soon as I have one.
Thanks again for giving us this important feedback and for describing your specific scenarios! It helps!
08-23-2019 10:45 AM
Agreed, we have used this policy for a long time, with IE, and when we rolled out Edge initially, this was the top requested design feature request, enabling single-word support for intranet sites.
08-29-2019 03:13 PM
Thank you for your patience and for the additional responses.
In the today's Canary build, the policy GoToIntranetSiteForSingleWordEntryInAddressBar is now available for you to try out. Using gpedit.msc, you can find the policy under Computer Configuration > Administrative Templates > Microsoft Edge and it's Setting title reads, "Forces direct intranet site navigation instead of searching on single word entries in the Address Bar".
Please test this out in your environments and let us know if this meets your needs. I'm particularly interested in feedback on the following:
Of course, I'd love to hear any other feedback you have related to this policy as well.
On behalf of the Microsoft Edge team, thank you!
08-30-2019 09:04 AM
Do you know what version of the admin templates this new policy is available in? I just now downloaded the latest published, and I can't find that policy.
The one downloaded shows:
08-30-2019 09:42 AM
Same here, downloaded latest DEV policy ADMX files, don't see the referenced policy setting.
08-30-2019 09:57 AM
08-30-2019 10:09 AM
Quick update. My suspicion upon reading @Aaron Roma's response was that the published ADMX files are for Dev channel and above only, however this policy has not been published to the Dev channel yet (currently, it's only available in Canary).
I was able to confirm that a few moments ago. Unfortunately, this means testing will have to wait until the next Dev channel build and its accompanying ADMX update.
Please be on the lookout for those updates at some point next week (barring any unexpected issues). I apologize for the delay and I look forward to your feedback once you're able to test this.
09-04-2019 12:10 PM
Update: The latest Dev build is out and its accompanying Dev policy file contains GoToIntranetSiteForSingleWordEntryInAddressBar, so this policy is ready for you to try out.
Using gpedit.msc, you can find the policy under Computer Configuration > Administrative Templates > Microsoft Edge and it's Setting title reads, "Forces direct intranet site navigation instead of searching on single word entries in the Address Bar".
Now that you're able to test this, please test this out in your environments and let us know if this meets your needs.
I'm particularly interested in feedback on the following:
Of course, I'd love to hear any other feedback you have related to this policy as well.
Thank you and hopefully this works for you this time :)
09-04-2019 01:56 PM
FYI, quick test with DEV build 78.0.262.0 and the latest DEV Policy files succeeded. In my test, single-word URL appended the trailing forward-slash and navigated to a local intranet site, as requested.
If the site is not available, it displays a "can't reach this page" error. Multiple words default to a Bing search, as expected.
This would work, but it would be a better user experience it if worked like IE 11, where if it can't resolve the single-word URL on the local intranet it sends the request for the URL to the default search provider, similar to EdgeC's default behavior.
We don't use the search provider or browser history deletion GPOs in our environment, so current implementation, although not ideal, would meet our needs.
Thank you for your continued support.
09-05-2019 02:22 AM
My preliminary tests have the same result as @AngelPRU.
The policy does what it says, but it would be a much better user experience if it would do a search engine search for the single word if it is not resolved internally instead of ending in a 404/"Hmmm... can't reach this page".
The policy for Internet Explorer worked this way, and Edge should too in order to be really user friendly.
I don't have time to do thorough testing with various search engine policies etc. right now as i am going on vacation tomorrow. But i will do more thorough testing when i get back in 2 weeks.
09-05-2019 09:12 AM
Same result here. Would expect it to automatically fail-over to do a search per the configured search engine if the short-name can't be resolved.
09-05-2019 06:16 PM
Thank you very much for testing so quickly and for already providing feedback! I'm glad to hear this largely meets your needs.
I've made a note about the request for a search fallback on timeout rather than the error message. I will discuss this with the team and we will look into it.
@ToMMeR, have a great vacation and I look forward to any additional feedback upon your return!
In the meantime, if anyone else has additional feedback about this policy, I will continue to monitor this thread.
09-06-2019 07:12 AM
Sorry for the delay, but I did finally get to test this policy as well. I also agree with the others that the preferred behavior would be do perform a search if the intranet site doesn't resolve.
That being said, I also noticed a different issue. This policy does not work if the intranet site has a dash "-" in the name. For example, typing in the single word "intranet" would correctly go to the "intranet" site. However "ab-intranet" would perform a search rather than resolving to an intranet site.
09-26-2019 03:52 AM
I have now had time for some more thorough testing combined with our typical search engine policies.
In general the solution works really well and is a big step in the right direction.
I do not experience the issue that @Aaron Roma mentions with dash "-" in the name. I tested on the newest Version 79.0.279.0 - maybe it's been fixed in this build?
I do however experience as issue with a dot "." which in our case is much worse.
As soon as i type the first dot "." in a hostname it changes from resolving the hostname to doing a search engine search. This is a serious issue as an internal website usually would be either just a hostname, or a FQDN which of course includes a dot "."
It looks like the logic behind the address bar somehow recognizes known top level domains like .com, .org etc., but if you are trying to resolve an internal FQDN the internal DNS name might be different, like hostname.company.local
Also as mentioned before, it would be much better if it could fallback to a search engine search if the hostname does not resolve within the timeout - the same was it worked in Internet Explorer. That way users can still do a single word search even though the policy is enabled, they will just experience a few second delay as the browser tries to resolve the word as a hostname before using a search engine.
09-26-2019 04:15 PM
Thanks, @ToMMeR and @Aaron Roma.
Yes, we included dashes per your feedback. I'm glad to hear that it's working for you. Our team is going to consider including dots as well per the examples provided above.
Question to this thread's audience and the rest of the enterprise community: are there any other punctuation characters (in addition to dashes and dots) you would expect would be considered part of a "single word" for direct intranet navigation?
As for the fallback to search upon timeout, I've made a note of that as well and added it to our backlog. It's not committed yet and I don't want to over-promise, but I hear the feedback and we're aware of the importance of search as a fallback as part of this policy functioning end-to-end for you. I'll keep this thread posted on any decisions related to this request.
Thanks again for the great testing and detailed feedback!