SOLVED

Policy needed: "Go to an intranet site for a one-word entry in the Address bar"

Brass Contributor

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.

53 Replies

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!

Jared

Hello @ToMMeR, @stesch79, @paf_skov@AngelPRU, @Aaron Roma, and @Omega47,

 

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,

Jared

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.

 

Thank you,
Jared

@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)?

@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.

Jared

@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!

 

Jared 

@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?

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:

  1. Right-click on the taskbar shortcut
  2. Right-click on the “Microsoft Edge Dev” item in the context menu which appears after step #1
  3. Click on “Properties” in the second context menu that appears
  4. In the “Target” field, please append “--enable-features=msAllowFallbackSearch” to “C:\Program Files (x86)\Microsoft\Edge Dev\Application\msedge.exe” such that the Target field looks like, “C:\Program Files (x86)\Microsoft\Edge Dev\Application\msedge.exe --enable-features=msAllowFallbackSearch”

 

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)

@JaredB81 Fantastic!

 

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.

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

@JaredB81 

 

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.

 

 

@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.

Does this work for Beta-Channel too?

@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

Hi Everyone,

 

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.


Happy Holidays!
Jared on behalf of the entire Microsoft Edge Address Bar & Search Team.

@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!

Jared

I just want to say that I love this thread. This is definitely something that is needed in an enterprise environment, and the fact that the developers have listened, implemented, and iterated so quickly is amazing.

@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 :smile:

 

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!

@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!

Hello everyone,

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.

 

Thank you,

Jared