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!
10-24-2019 12:18 PM
We have implemented support for the dot character much like our implementation to support the dash character. The implementation should be available in the next Dev channel release. Once the build is available, please test it and give us your feedback.
As for the search fallback on timeout request, we are actively investigating the safest way to implement this aspect of the policy. The relevant codepath is very complex and so it requires a detailed and carefully thought out design. We are taking your feedback seriously and I will keep this thread updated as we make progress here.
Thanks very much,
10-29-2019 11:18 AM
Update: Dev channel build 79.0.309.5 has been released. It should contain support of dots for single-word direct navigation if the policy is enabled.
@ToMMeR, please test this out and let us know how it works for you.
10-30-2019 12:27 AM
@JaredB81 in version 79.0.309.5 the logic behind when to search and when to visit a website still seems strange and in a way that would lead to quite a lot of search engine searches where a internal website was what was intended.
Take "test.vejle.intern" as an example which could be an internal hostname.
- "test" correctly tries to go to the hostname.
- "test." tries to do a search engine search (why?).
- "test.v" still tries to do a search engine search.
- "test.ve" correctly tries to go to the hostname.
- "test.vej" tries to do a search engine search.
- "test.vejl" still tries to do a search engine search.
- "test.vejle" still tries to do a search engine search.
- "test.vejle." still tries to do a search engine search.
- "test.vejle.i" still tries to do a search engine search.
- "test.vejle.in" correctly tries to go to the hostname.
- "test.vejle.int" correctly tries to go to the hostname.
- "test.vejle.inte" tries to do a search engine search.
- "test.vejle.inter" tries to do a search engine search.
- "test.vejle.intern" tries to do a search engine search.
I do not understand why the logic behind it has to be this complex.
When the group policy is set, why don't you just treat anything a hostname until a character that is not valid in a URL is typed (like for example a space)?
10-30-2019 01:36 PM
@ToMMeR, thank you for your feedback.
Your testing did not match my expectation and after looking into it, it turns out the fix didn't make it into the 79.0.309.5 Dev channel build. Our team has now checked in the fix to make sure it is in the next Dev channel release. I'll update this thread once that has taken place and then I'll kindly request you run these test cases again.
Thank you for your patience and I apologize about the confusion.
11-05-2019 10:28 AM
@ToMMeR, the "dot" fix should now be available in the latest Dev build (79.0.309.11). Please give it a try and let us know how it works for you.
@ToMMeR, @Aaron Roma, @Omega47, @AngelPRU, @paf_skov and @stesch79, we have determined a feasible and safe approach to enable the search fallback behavior. Development is underway and once the solution has been implemented, I will update this thread so we can get your feedback on the search fallback behavior.
On behalf of the Microsoft Edge team, thank you again for testing and for your valuable feedback! We appreciate it!
11-07-2019 11:39 PM
@JaredB81 I can confirm that "." (dot) now works as expected.
It correctly keeps to a hostname when you do dots and dashes and doesn't do a search engine search until you type a space.
Thank you for the fix!
Any status on the ability to fail back to search after a few seconds if the hostname is not resolved?
I can see that build 79 is heading to GA, so I am wondering how long we have to wait for this until we can deploy a GA Edge version to our users?
11-13-2019 04:23 PM
Thank you, @ToMMeR for confirming the dot fix works as expected! I'm glad to hear it meets your needs.
@ToMMeR, @Aaron Roma, @Omega47, @AngelPRU, @paf_skov and @stesch79, as for the search fallback, I'm pleased to report that we have an implementation ready for you to test! It should be available in the latest Dev channel build (80.0.320.5).
Since the implementation is in such a complex area of our codebase, we have put the fallback behind a command-line feature flag until we have sufficient test coverage to conclude it is behaving as expected, without any unintended consequences.
To test the search fallback, in addition to enabling the policy, please edit your shortcut for Edge Dev to include the feature flag.
Here are instructions:
Please update to the latest Dev channel build, apply the policy to go to an intranet site for single word entries, set the feature flag in your shortcut and launch Edge dev using that shortcut. You can then attempt to navigate to single word destinations that are not within your Intranets.
Please let us know how the fallback behavior works for you.
As always, thank you very much for your feedback!
Jared (and the entire Microsoft Edge Address Bar & Search Team)
11-14-2019 01:03 AM
I have tested the implementation and it works as expected.
I have tried various combinations of single word entries, and entries with "." and "-".
If the word is not resolved in our DNS it instantly does as Google Search.
If the word exists as a hostname in our DNS, but no web server responds to the request, then it also redirects to a Google Search after timing out (which takes about 20 seconds). This is of course quite a long time to wait, but I think it is acceptable as if the word exists as a hostname in DNS you are most likely trying to access that web server and not search for the word.
I will continue to run on the this Edge Dev version with the feature enabled and let you know if i stumble upon anything unexpected. But I think it works as wished :)
Thank you for implementing this feature.
11-14-2019 10:12 AM
Thank you, @ToMMeR, for testing our implementation and for confirming this policy now meets your needs, end-to-end, for your organization.
We will continue to monitor feedback from other members of the community and I would love to hear how others on this thread find the experience once they have done similar testing.
We will also continue to conduct internal testing to make sure navigating and searching work seamlessly when this policy is enabled. Once we have completed our testing and have heard from anyone else from the community who is testing the policy with the search fallback command-line flag enabled, we will remove the requirement to set the command-line flag. I’ll post an update on this thread when that takes place.
Finally, @ToMMeR, I would be remiss as a member of the Address Bar and Search team to respond to your post without suggesting that you give Bing a try :-). Particularly with the new Microsoft Search in Edge feature which is designed to help members of your organization be even more productive, but with Bing relevance and performance improvements in general, we are working hard to make Bing the very best search experience in Microsoft Edge! Please give it a try – I’d love feedback on how Bing works for you as well :-).
Thanks very much,
Jared on behalf of the entire Address Bar and Search Team
11-14-2019 10:35 AM
Completed my test cycle, all is working as expected / requested. I have not come across any issues but will ask some of my peers to run additional test and will report back if needed. Thank you for your support, appreciate the effort.
11-15-2019 12:36 AM - edited 11-15-2019 12:37 AM
@JaredB81 I have found a scenario where Edge does not react the way I intended/wished.
We have some internal websites that is using a self signed certificate not from our CA (Usually test systems, or appliances where it for some reason have been decided not to change the certificate).
This of course results in the "Your connection isn't private" (NET::ERR_CERT_AUTHORITY_INVALID) screen where you can then choose to continue even though it is "unsafe".
These systems do redirect to HTTPS if you try to access them on HTTP.
When trying to access one of these websites using just their hostname I very quickly see the redirect to HTTPS as i see the "Your connection isn't private" for a split second and then i am redirected to a search engine search.
11-22-2019 12:49 PM
@Thilo Langbein, the policy and most of the functionality enabled by this policy which this thread discusses is available in the Beta build. The fallback to search component of this policy is not yet in Beta. Once Beta moves over to the 80.x build numbers, it will get the fallback to search functionality. We expect Beta will move over to the 80.x build numbers closer to our release of the Stable channel (which is scheduled for 1/15/2020).
@ToMMeR, thank you for the bug report. I have sent you a private message to get some more details about your specific issue. Please reply at your earliest convenience and we will look into it.
Thanks, everyone for the continued feedback and have a great weekend!
Jared and the entire Microsoft Edge Address Bar and Search Team
12-20-2019 11:17 AM - edited 12-20-2019 11:19 AM
Just in time for the holidays, we have a fix for the issue with navigating to internal sites that are self-certified.
The fix just got checked in this week, and will be available in an upcoming build (currently Edge 81 builds, which aren't out yet). We will look into the possibility of including this fix in Edge 80.
@ToMMeR, please stay tuned and I will update this thread when we have a build you can test.
Thanks again for your feedback and for working with us to make sure the new Microsoft Edge works as well as possible in your enterprises! We really appreciate it.
Jared on behalf of the entire Microsoft Edge Address Bar & Search Team.
01-09-2020 09:44 AM
@ToMMeR, the cert fix is now checked into both Edge 81 and Edge 80. You should be able to validate with both Canary and Dev channels.
To test the fix, please manually add the command line flag “--enable-features=msAllowFallbackSearch” to your Edge shortcut.
Please let us know if the fix meets your needs.
Thank you very much!
01-09-2020 11:29 AM
01-10-2020 12:18 AM - edited 01-10-2020 12:19 AM
@JaredB81 I have tested with build 81.0.381.0 in the DEV channel and can confirm that it works as expected now.
When you type the hostname of a website that redirects to https and doesn't have trusted certificate Edge correctly stays on the site and does not do a search engine search, just like expected.
When you type a single word (whether it is including dash, dots or no special characters) that does not exist as a hostname, you briefly (maybe half a second or less) see the "unresolved hostname" page and then you are redirected to a search engine search.
I think the way this works is acceptable
I am looking very much forward to this build reaching production - this is the first build we would want to implement in our organization.
Can you please let us know which build number this would be included in by default (without the command line flag)?
I completely agree with @Steve Whitcher. This is the first time i have experienced this easy access to developers at Microsoft, that customer wishes have been accepted, prioritized and implemented this quickly.
So a big thank you to @JaredB81 and your team for this!
01-10-2020 03:42 PM
@ToMMeR, excellent! I'm very glad to hear that the fix for the no-trusted-certificate case is working as expected and that the other cases (dots, dashes, search fallback, etc.) continue to work as you expect.
@Steve Whitcher and @ToMMeR and to everyone else on this thread, we want to thank you! Thank you for spending time to test our Insider builds and to provide feedback. While our team is committed to delivering a great experience, it is with your feedback that we are able to do so, particularly for cases that are specific to your organizations.
As for which Stable release will contain this full end-to-end solution including the cert fix, by default, without any command line flags, we are aiming for the Edge 80 Stable release (so not the build we announced is going to the Stable channel when it first goes live next week, but the subsequent major Stable release which will follow it).
We will have a build in Canary and Dev that removes the command line flag sooner than that however, so you'll be able to more easily test the cert fix and share it with other members of your organizations. I'll update this thread once we've removed the flag and enabled the fix by default.
Finally, please keep any other feedback about the new Microsoft Edge coming! Feel free to start new threads about other features/scenarios and if your feedback is about the Address Bar or Search, feel free to @ mention me.
On behalf of the Address Bar and Search team, thanks again and have a great weekend!
01-29-2020 12:23 PM
I wanted to post an update on the timing of the on-by-default state. We are a little bit late to take that change into Edge 80 Beta and rather than rush it and risk that a regression makes it way into the Stable channel, we are going to take the change into the Beta channel once Beta moves to Edge 81.
This means that the full, end-to-end functionality of this policy as this audience has validated it, will still require a command line flag in the Stable channel until Stable moves to Edge 81.
As we are updating Stable channel with major releases every 6 weeks, the delay isn't very long, but I didn't want anyone to expect this when Stable moves to Edge 80, and be surprised that it was missing.
I apologize for the delay and I'll update this thread once the Beta channel has Edge 81.
02-21-2020 02:45 PM
Just a brief update that the search fallback behavior is now on by default (no command-line flag needed) if this policy is enabled in the Beta channel as Beta has reached version 81.
If you plan to deploy the Stable channel of Edge throughout your organization, this policy will include the search fallback behavior without any command-line flags necessary to enable it, when the Stable channel reaches version 81.
Please test this out in Beta and let us know if anything is not working as expected.
04-23-2020 01:49 PM
Thank you for the head's up, @Thilo Langbein. First, I hope you and everyone else in this community is safe and well.
The policy seems to have been omitted from the latest published ADMX and ADML files. I'll look into why that took place and work to get the policy back ASAP.
I apologize for this inconvenience and I'll update this thread when I have an ETA for the policy's return to the administrative templates.
04-23-2020 11:50 PM
@JaredB81 Thanks. Policy sems to be inplace and is shown under edge://policy but it doesn't work in Dev84.
04-29-2020 02:40 PM
@Thilo Langbein, thanks for the clarification. The policy did get into the template files but a change from Chromium upstream broke the implementation of the policy if configured.
The fix has been in Edge Canary for a few days and the latest Dev build has the fix as well. Please test with the latest Dev build and let us know if you encounter any issues.
Thank you and again, I apologize for the inconvenience this caused!
04-30-2020 12:20 AM - edited 04-30-2020 12:21 AM
@JaredB81 With Dev 84.0.495.2 one-word-intranet has come back. Thanks folks.