How to block Bing Chat public for organization users and allowing Bing Chat Enterprise

Copper Contributor

Bing Chat Enterprise is made available for enterprise users.  However there is possibility that users might be using Bing Chat public.  Is there a way to force BCE for Organization users and block Bing Chat public.

12 Replies
Hi Vimaleshwara, currently there is not a way to block Bing Chat public without also blocking Bing Chat Enterprise. If this changes, we will update our documentation and notify customers. We recommend leaving BCE turned on, as turning BCE off does not turn off all chat; instead, chat reverts to Bing Chat public, which does not offer BCE's commercial data protection.
You can block the public version of Bing chat by creating a CNAME in DNS for that points to Of course if you are running MS DNS servers this task is nearly impossible without screwing up the rest of the domain. What I had to do was install DNS on a secondary server that my clients do not use directly with the primary zone and a CNAME for www pointing to Then I setup a conditional forwarder for on my real DNS servers that forwards the request to the secondary server.

@Vimaleshwara Gajanana @Bradley Fox 

I followed the above suggestion to block the public version, and it worked great.  Users could only get to when signed into edge with corporate profile.


Ignite today announced  It's basically the same thing, hosted from a different dedicated URL.  Unfortunately, this bypasses the previously suggested method to block the public version.  Looking for info on how to now force enterprise only version.

But how do you create a primary zone and a CNAME for www pointing to hosted by DNS servers? Won't the secondary DNS server also be answering for Since the zone is on it.
Wouldn't you need to create a A record for as well? Thereby losing the whole point of using a CNAME?

No, because you only have a conditional forwarder setup for which then forwards to the secondary DNS server that holds the CNAME for which sends the client to which would be queried on the primary DNS server.  Since there is no domain on the primary and no conditional forwarder it will use either root hints or your regular forwarders to lookup

Yes, you are right! I just figured it out as well. It only forwards the query to my secondary DNS server. it looks up via DNS servers. Works like a charm.

For now, I've just blocked and informed my users to access Bing chat from Edge or from  Microsoft says this functionality is coming for but they don't say when...


Manage Copilot | Microsoft Learn

@Vimaleshwara Gajanana I tried this and it does not work in MS DNS.  You cannot create a conditional forward at the zone root level so on the production DNS this means to create a conditional forwarder for you must create the zone.  After doing this the prod DNS server answers queries. When I try to create a delegation at the root the "Next" box is greyed out unless I input a subdomain so I am unable to create a delegation for in the zone.  Likewise, I am unable to create a CNAME at the root of the zone either. As it was described it does not work.  Maybe you could provide the steps that worked or the work around that made it possible to delegate only without have a zone record for in MS DNS.

You have to use two DNS servers. Your regular Prod server that's setup in client DNS settings and another secondary DNS server that clients know nothing about. Zone with Alias goes on the secondary, conditional forwarder goes on the primary.
OK, Here goes for This one requires TWO conditional forwarders because Microsoft, in their infantine wisdom, made the redirect a subdomain of the original domain which effs everything up.

What we're trying to do: Redirect to to force data protection in copilot.

On your secondary DNS server (the ones the clients know nothing of) create the primary zone Add a CNAME for and point it at

Back to the production server. Create TWO conditional forwarders here.
The first is that sends the requests to your secondary DNS server to get the CNAME.
The second is which should send the request out to the internet (I'm using and

The second is required because if it tries to resolve itself, it just uses the first conditional forwarder again which sends the request in an infinite loop between your DNS servers.

@Bradley Fox , great hack! 

I'll mention that anyone using some kind of DNS firewall or Response Policy Zone for DNS can easily create a policy rule to match both names and have the DNS server artificially generate the CNAME response without all the configuration flaming hoops...

As Microsoft DNS Policies do not appear to support a redirect action (see: ), one is left to implement the feature at the forwarding/recursion/caching level of your DNS infrastructure with BIND or other non-microsoft DNS solutions.

for examples of how to get RPZ to generate a CNAME based on a policy match. 

And RPZ is a standard feature on pretty much any Protected DNS service out there.