Welcome to the April 2024 edition of What’s New in Copilot for Microsoft 365! Every month, we highlight new features and enhancements for Copilot for Microsoft 365, so you can stay up to date with Copilot features that help you be more productive and efficient in the apps you use every day. This month, we’re excited to share information about extended language support in Copilot, features to help streamline data in Copilot in Excel, more efficient search and document creation with Copilot in Word, new training in Copilot Academy, and so much more!  

And in case you missed it, be sure to catch up on our recent announcement about general availability of Microsoft Copilot Dashboard, as well as our quarterly blog series designed to help you skill up on Modern Work technologies. 

Now let’s take a look at this month’s updates:

Expanded capabilities

Copilot with Graph-grounded chat now available in Outlook
Use local files to ground Copilot prompts
Create and consume Word documents more efficiently with Copilot
Generate multiple formula columns with Copilot in Excel
Fine-tune prompts with Notebook in Copilot with commercial data protection

Expanded access and management

App Assure now supports Copilot customers transitioning to monthly updates
Support for new languages in Copilot for Microsoft 365
Improve Copilot skills with Copilot Academy in Viva Learning
Manage Copilot availability in Teams meetings
Restricted SharePoint Search now in Public Preview

Copilot with Graph-grounded chat now available in Outlook

Starting in May, you can use Copilot in Outlook to connect to and reason across your enterprise data including your chats, documents, meetings, and emails. You will find the Copilot app in the left app bar in classic Microsoft Outlook for Windows, new Outlook for Windows, and Outlook on the web. Learn more about using Copilot with Graph-grounded chat. 

A screenshot of a computer showing a Copilot chat box in Outlook

Use local files to ground Copilot prompts

Using Copilot to reason across your work data is becoming more comprehensive and simple. Since we launched Copilot, you have been able to ground your prompts in specific files stored in One Drive or SharePoint by typing “/” and then the file name. In May, we’ll add the ability to ground your prompts in local files, too. And for files stored in the OneDrive and SharePoint, you’ll soon be able to simply copy and paste file links to ground prompts for even richer conversations with Copilot. 

Create and consume Word documents more efficiently with Copilot

Now, you’ll see several new features in Copilot for Word that can help you access information quickly when you’re creating documents. 

Now when you ask Copilot a question in Word chat, an answer will be generated using the rich, people-centric data and insights in the Microsoft cloud and Microsoft Graph. That way, you can stay in the app and maintain focus on creating your document. 

A blank Word document with Copilot open on the side. The user prompted Copilot “I’m writing a proposal for a corporate event in Europe. What are some considerations regarding collecting names and emails of attendees?”. Copilot responded based on information from the users accessible work files, including a specific reference for Email templates that links to an internal document.

And when you use the Rewrite feature in Copilot, now you can fine-tune a specific section of the document. This gives you more control over additional changes, re-writes, tone, and formatting with the help of Copilot . 

A user has a Word document open. They select a specific section called “Project Timeline”, open Copilot, and in the “Fine-tune” section enter “Include details about the budget. Copilot edits the selected text based on the prompt.

You can use Draft with Copilot to reference files that are marked with sensitivity labels to create a new document draft, and the sensitivity label of the referenced file will be automatically applied to the new draft.  

A GIF shows a user with a blank Word document open. They activate Copilot and request to “Create a 1-page presentation” using two files. An “i” icon indicates that one of the files has a sensitivity label. Copilot generates the new document, and a yellow banner appears, indicating that Copilot automatically applied the sensitivity label from the referenced file.

Copilot can create summaries of selected text. Simply select the text block you want summarized and ask Copilot to provide a summarized version you can share in other documents or email. This is available in Word for web now. 

An image of a Word document for a Go-to-market strategy. The user has highlighted a section of the text and prompted Copilot so summarize. Copilot shared a summary of the selected text.Beginning in May, if you are using Copilot in Word to draft a document, you can copy and paste a link of a supported file as a reference into Draft with Copilot, instead of searching for it in the file reference menu. This makes it faster for you to find any reference files you need to support your work. 

Generate multiple formula columns with Copilot in Excel

Copilot in Excel now supports generating multiple formula columns from a single prompt. Ask one question, and Copilot can return two formula columns simultaneously. For instance, you can extract both the first name and last name from a single prompt, neatly separating the information into distinct columns. Additionally, now you can use Copilot to create complex formula columns that span across multiple tables, utilizing functions like XLOOKUP and SUMIF. This capability streamlines data processing and empowers you to handle more complex data analysis tasks efficiently, even when using multiple tables. 

Securely access Copilot web chat in the Copilot mobile app  

Now you can access AI-powered web chat on the go with the Copilot mobile app available on iOS and Android. When you sign into a work accounteligible license, Copilot (formerly Bing Chat Enterprise) automatically adds commercial data protection at no additional cost. This helps you be more productive and creative while also ensuring sensitive data is protected from being leaked into AI models. IT admins can manage the Copilot mobile app with Microsoft Intune. Learn more about Copilot on mobile.  

Fine-tune prompts with Notebook in Copilot with commercial data protection

Notebook is a new way to securely interact with the generative AI models powering Copilot—beyond chat, Notebook is like an enhanced scratch pad that lets you fine-tune your prompts. Notebook allows for longer prompts and lets you iterate and refine your prompt over time to get the response you’re looking for. These capabilities make it especially useful for tasks like generating code or developing a piece of writing. It’s also a great way to experience how adding more details to your prompts can produce better responses. 

Commercial data protection applies while using Copilot, just sign in with an eligible work or school account. You can access the Notebook feature at the top of copilot.microsoft.com and Copilot in Bing. If you have a Work and Web toggle at the top of the Copilot experience, set the toggle to Web to see Notebook. 

A screenshot of a computer showing a Copilot chat box with a Notebook icon above it.

App Assure now supports Copilot customers transitioning to monthly updates

Starting today Microsoft’s App Assure program now supports Copilot for Microsoft 365 customers moving to a monthly update channel, at no additional cost. As more organizations adopt Copilot, they’re moving to a monthly update channel for Microsoft 365 Apps. 

Companies that move to a monthly update channel get the latest features and custom rollout waves. In addition, monthly updates provide a secure experience that minimizes incidents and disruptions, offer better diagnostics for supportability and minimize helpdesk claims. For customers who need a predictable release schedule, we specifically recommend the Monthly Enterprise Channel.  

The App Assure program underscores our commitment to delivering a seamless experience offering app compatibility assistance across line of business applications, third-party software, and Microsoft’s products: macros, add-ins, and drivers. For third-party apps, App Assure will work directly with qualified participants to resolve app compatibility issues. Register for app assure today.  

Support for new languages in Copilot for Microsoft 365

We are now rolling out support for an additional 16 languages in Copilot for Microsoft 365 including Arabic, Czech, Danish, Dutch, Finnish, Hebrew, Hungarian, Korean, Norwegian (Bokmal), Polish, Portuguese (Portugal), Russian, Swedish, Thai, Turkish, and Ukrainian. These join the growing list of languages in which Copilot is already supported: Chinese (Simplified)​​, English (US, GB, AU, CA, IN)​​, French (FR, CA)​​, German​​, Italian​​, Japanese​​, Portuguese (BR)​​, and Spanish (ES, MX)​​. 

In addition, we are also making Chinese (Traditional) available on Copilot for Microsoft 365, meaning that you can now to work with Copilot using that language just as you can in free versions. We will add Chinese (Traditional) to the list of supported languages as the last few known issues are resolved. Learn more about supported languages for Microsoft Copilot here.  

We are always improving. Today, Copilot for Microsoft 365 may not yet understand every colloquial expression or linguistic convention in a given language. We are continually refining Copilot’s language capabilities and encourage you to provide us with actionable feedback. We are also continuing to expand the list of supported languages and will share more in coming months.  

Improve Copilot skills with Copilot Academy in Viva Learning

Earlier this month we were excited to introduce Microsoft Copilot Academy. Recognizing the need to develop a new skillset around AI tools, Copilot Academy provides structured educational content to help you learn about, discover, and use Copilot quickly and effectively. Copilot Academy is generally available now, available in your Viva Learning app in Teams or the web.  

A computer screenshot showing Microsoft Copilot Academy in the Viva Learning app in Teams

Manage Copilot availability in Teams meetings

If you’re a Microsoft 365 admin, now you can manage Copilot availability in the Teams admin center. Either select an existing policy or create a new one, and then select On or On only with retained transcript from the dropdown for the Copilot setting:  

When you select On and a meeting organizer with this policy creates a meeting or event, then the Copilot option is set so it is available Only during the meeting. The meeting organizer can change this value to During and after the meeting. 

When you select On only with retained transcript and a meeting organizer with this policy creates a meeting or event, then the Copilot option is locked to During and after the meeting and the meeting organizer must turn on transcription to use Copilot.  

Restricted SharePoint Search now in Public Preview

Restricted SharePoint search began rolling out in public preview for Copilot for Microsoft 365 customers earlier this month. If you’re a Microsoft 365 admin, this enables you to review your content management and data governance practices without losing momentum with your Copilot deployment. You can disable organization-wide search to restrict both enterprise search and Copilot experiences in the SharePoint sites of your choice. Restricted SharePoint search will be generally available in May 2024. To follow the status of the rollout, please check the public roadmap. 

Copilot for Microsoft 365 end user experience. There is a message at the top of the screen with the following text: “Your organization’s admin has restricted Copilot from accessing certain SharePoint sites. This limits the content Copilot can search and reference when responding to your prompts. Learn more.”

Did you know? The Microsoft 365 Roadmap is where you can get the latest updates on productivity apps and intelligent cloud services. Check back regularly to see what features are in development or coming soon. 

​Microsoft Tech Community – Latest Blogs –Read More 

This blog post aims to walk you through the setup of an autoscaled application on Azure Kubernetes Service (AKS) with Kubernetes-based Event-Driven Autoscaling (KEDA), activated by Microsoft SQL Server (MSSQL) queries. By following this guide, you will have an autoscaled application in place, facilitating efficient resource utilization and equipping your application to manage fluctuating workloads, thereby enhancing its performance and responsiveness.

Prerequisites:

Azure Account: An active Azure account is required. If you do not have one, you can sign up for a free account on the Azure website.
Kubernetes Familiarity: A basic understanding of Kubernetes concepts, including Deployments, Services, and Persistent Volumes, is essential.
SQL Server Knowledge: Basic knowledge of SQL Server and SQL queries is necessary, as MSSQL will be used as a KEDA trigger.
Tools Installation: Ensure that Azure CLI and kubectl are installed on your local machine.

To install the KEDA add-on, use –enable-keda when creating or updating a cluster. You can find the different installation options in this Microsoft documentation: Install the KEDA add-on with Azure CLI.

Create a new AKS cluster using the az aks create command and enable the KEDA add-on using the –enable-keda flag.
az aks create –resource-group myResourceGroup –name myAKSCluster –enable-keda

To begin, we will deploy a SQL Server container on Azure Kubernetes Service (AKS). For guidance, you can consult the official Microsoft quickstart guide on running SQL Server containers on Azure: Deploy a SQL Server container cluster on Azure.

The deployment process is as follows:

Provision Persistent Storage: We will create a StorageClass for Azure Disk to ensure our MSSQL data has persistent storage.
Create a Persistent Volume Claim (PVC): We will define a Persistent Volume Claim (PVC) that utilizes the previously created StorageClass. This PVC will dynamically provision Azure Disks for storing MSSQL data.
Deploy MSSQL: We will deploy MSSQL using Kubernetes manifests, designating the previously created PVC for persistent storage.

The YAML files necessary to create the StorageClass, Persistent Volume Claim, and a Microsoft SQL Server (MSSQL) instance on Azure Kubernetes Service (AKS) can be found in the following GitHub link: GitHub link for Kubernetes Autoscaling with KEDA and MSSQL on AKS.

In this blog, we have set up a deployment called “mssql-deployment” for MSSQL with a single replica and a Kubernetes Service of type LoadBalancer to facilitate external access. The external IP provided by this service will be used to connect to the SQL Server container via SSMS from our local machine. The following section will cover the creation of our web app deployment and the process of connecting it to this MSSQL Server instance from the application.

Deploying and Exposing Your Web Application on Azure Kubernetes Service:
In the preceding sections, we covered setting up persistent storage and deploying a Microsoft SQL Server (MSSQL) instance on Azure Kubernetes Service (AKS). We will now proceed to deploy and expose our web application. For further information on deploying an application to Azure Kubernetes Service (AKS), you can refer to this Microsoft tutorial: Tutorial – Deploy an application to Azure Kubernetes Service (AKS).

Below are the sample Kubernetes deployment and service manifest files featured in this blog. These scripts are available at the following GitHub link: GitHub link for Kubernetes Autoscaling with KEDA and MSSQL on AKS.

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
selector:
matchLabels:
app: webapp
replicas: 1
template:
metadata:
labels:
app: webapp
spec:
containers:
– name: webapp
image: yourdotnetimage/webapp:dotnet-v7.0.1.01
ports:
– containerPort: 80
resources:
limits:
cpu: 300m
memory: “100Mi”
requests:
cpu: 100m
memory: “50Mi”
env:
– name: ConnectionStrings__WebAppContext
value: “Server=mssql-deployment;Database=ProdcutsDB;User ID=SA;Password=yourpasswordhere;Encrypt=False;”
—
kind: Service
apiVersion: v1
metadata:
name: webapp-service
spec:
selector:
app: webapp
ports:
– protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer

After applying the manifest files mentioned above, we should see the deployments and services for both the SQL Server and the web app created on our AKS cluster. It’s important to note that both services are assigned an external IP, allowing us to connect to our containers via the internet.

To interact with MSSQL from your local machine, follow these steps:

Get External IP: Retrieve the external IP of the MSSQL Service using the “kubectl get svc” command, as indicated in the screenshot above.
Configure SSMS: Use the external IP to configure SQL Server Management Studio (SSMS) on your local machine. Specify the external IP as the server’s name and use SQL Server Authentication with the provided credentials.

Be aware that this approach makes your SQL Server accessible over the internet, which may not be secure. Always protect your SQL Server with a firewall and establish secure connections. After connecting to the SQL Server with SSMS, proceed to create a table and insert data as illustrated below to emulate workload variations.

— Check if a table named ‘backlog’ exists in the ‘dbo’ schema
IF NOT EXISTS (SELECT * FROM sys.tables WHERE name = ‘backlog’ AND schema_id = SCHEMA_ID(‘dbo’))
BEGIN
— If the ‘backlog’ table does not exist, create it with columns ‘id’ and ‘state’
CREATE TABLE backlog (
id INT IDENTITY(1,1) PRIMARY KEY, — ‘id’ is an auto-incrementing integer
state VARCHAR(50) — ‘state’ is a variable character string with a maximum length of 50
);
END

— Declare a variable named ‘@counter’ and initialize it with the value 1
DECLARE @counter INT = 1;
WHILE @counter <= 50 — Start a loop that will run 50 times
BEGIN
— Insert a new row into the ‘backlog’ table with ‘state’ set to ‘queued’
INSERT INTO backlog (state) VALUES (‘queued’);
— Increment the ‘@counter’ variable by 1
SET @counter = @counter + 1;
END;

The script begins by verifying the existence of a table called ‘backlog’ within the ‘dbo’ schema. If it doesn’t exist, the script proceeds to create this table with ‘id’ and ‘state’ columns. In our demonstration, this action will result in the creation of a new ‘backlog’ table. Subsequently, a loop is initiated that executes 50 times; during each cycle, a new ‘queued’ state row is added to the ‘backlog’ table.

Therefore, if we execute a count query on the ‘backlog’ table for rows where the ‘state’ is ‘queued’, we should expect the result to be 50.

SELECT count(*) FROM backlog WHERE state = ‘queued’

From our AKS cluster, we can verify the number of pods by using the command “kubectl get pods,” which shows the web app and the MSSQL pods operating as anticipated (below screenshot)

Autoscaling Applications on Kubernetes with KEDA and MSSQL:
Now, let us examine the YAML configuration that illustrates autoscaling a Kubernetes application in response to the load on a Microsoft SQL Server (MSSQL) database, utilizing Kubernetes Event-Driven Autoscaling (KEDA). Various methods exist for employing the Trigger Specification for MSSQL. In this blog, we demonstrate the deployment of a scaled object using the mssql scale trigger, which incorporates TriggerAuthentication and a connection string:  KEDA Documentation.

apiVersion: v1
kind: Secret
metadata:
name: mssql-secrets
type: Opaque
data:
mssql-connection-string: echo “Server=mssql-deployment.default.svc.cluster.local;port=1433;Database=ProdcutsDB;Persist Security Inf
o=False;User ID=SA;Password=MyC0m9l&xP;Encrypt=False;TrustServerCertificate=True;” | base64
—
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-trigger-auth-mssql-secret
spec:
secretTargetRef:
– parameter: connectionString
name: mssql-secrets
key: mssql-connection-string
—
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: mssql-scaledobject
spec:
scaleTargetRef:
name: webapp # e.g. the name of the resource to scale
pollingInterval: 1 # Optional. Default: 30 seconds
cooldownPeriod: 30 # Optional. Default: 300 seconds
minReplicaCount: 1 # Optional. Default: 0
maxReplicaCount: 15 # Optional. Default: 100
triggers:
– type: mssql
metadata:
targetValue: “5”
query: “SELECT count(*) FROM backlog WHERE state = ‘queued'”
authenticationRef:
name: keda-trigger-auth-mssql-secret

The above configuration begins by creating a Kubernetes Secret named ‘mssql-secrets’, which securely stores the base64-encoded MSSQL connection string. Kubernetes Secrets are designed to protect sensitive information like passwords, OAuth tokens, and SSH keys. Subsequently, a ‘TriggerAuthentication’ custom resource named ‘keda-trigger-auth-mssql-secret’ is established, specifying the authentication method KEDA will use with the MSSQL server, referencing the previously created ‘mssql-secrets’ Secret.

The configuration then introduces a ‘ScaledObject’ custom resource, which associates with the ‘TriggerAuthentication’ and defines how KEDA will modulate the deployment scaling in response to the MSSQL server load. The ‘triggers’ section contains a single ‘mssql’ trigger type, signifying KEDA’s reliance on a Microsoft SQL Server (MSSQL) database for the metrics needed to make scaling decisions.

In the ‘metadata’ portion, the ‘mssql’ trigger configuration is detailed as follows:

‘targetValue’: The metric threshold KEDA targets to maintain by scaling the deployment’s pod count up or down, set here to “5”.
‘query’: The SQL query “SELECT count(*) FROM backlog WHERE state = ‘queued'” tallies the ‘backlog’ table entries with ‘state’ set to ‘queued’. KEDA executes this query on the MSSQL server to ascertain the current metric value.

This configuration directs KEDA to scale the application based on the number of ‘queued’ tasks in the ‘backlog’ table. Should the count surpass 5, KEDA will scale up the application; if it drops below 5, it will scale down.

Once KEDA is configured, it’s applied to the Kubernetes cluster. KEDA then persistently monitors the defined MSSQL metrics, dynamically adjusting pod numbers to ensure optimal performance and resource efficiency. For instance, if there are 50 ‘queued’ tasks, KEDA will respond accordingly to manage the load. The screenshot below verifies that our web app scaled to 10, as there are 50 ‘queued’ tasks and the “targetValue” is 5.

It is crucial to ensure that the “READY” column in “scaledobject.keda.sh/keda-demo-sql” is “True”. If it is not, the scaling process will fail. Common errors typically arise from using an incorrect connection string, referencing an incorrect deployment, or errors in the configuration file specifications.

To demonstrate that our application scales down when the query output is zero, we should delete all rows from the “backlog” table using the below SQL command. It’s important to note that this command will only remove the contents of the table, not the table itself.

— Delete all rows from the ‘backlog’ table
DELETE FROM backlog;

Upon checking the number of pods after a brief interval, the output will be as depicted in the screenshot below. There is one webapp pod due to the “minReplicaCount = 1” setting in our KEDA configuration. Indeed, the KEDA configuration allows scaling down to zero, which is not possible with the Kubernetes native Horizontal Pod Autoscaler (HPA): Horizontal Pod Autoscaler (HPA)

Summary

This guide has detailed the steps for deploying a .NET application and Microsoft SQL Server on Azure Kubernetes Service (AKS). Additionally, we’ve set up Kubernetes Event-Driven Autoscaling (KEDA) to dynamically scale our application in response to MSSQL queries. This method enables efficient resource management and ensures that our application remains performant and responsive under different load conditions.

Special thanks to Ayobami Ayodeji, Senior Program Manager, who leads teams developing technical assets for Azure’s container services, for reviewing this content.

​Microsoft Tech Community – Latest Blogs –Read More 

Introduction

When migrating from Oracle to SQL Server, Azure SQL Database or Azure SQL Managed Instance, an application using the Microsoft JDBC Driver for SQL Server is often used to avoid re-writing the application. However, after migration it’s often discovered that performance is not the same as it was when the data was on Oracle. Optimizations are necessary for query tuning due to the distinct behaviors of the two database engines.

An unnoticed yet significant issue arises from implicit conversions due to JDBC driver settings, leading to performance degradation. This blog seeks to highlight this easily overlooked problem, offering solutions to ensure optimal performance with SQL backend while preserving the JDBC application.

How to Detect Implicit Conversion

Obtain execution plans for your most CPU-intensive queries by enabling the query store. Be aware that implicit conversions might be happening in smaller queries with high execution counts, even if they don’t individually consume significant resources. An easy way to identify the type conversion is given in this blog.   

Looking at the execution plan you would see something like this:

While if you look at the statement text, you will see that the JDBC Driver presents the statement like this, which looks innocuous:

(@P0 nvarchar(4000),@P1 nvarchar(4000))select col1, col2 from table1 where col1 = @P0 ….

Nevertheless, implicit conversion will result in queries consuming more CPU resources than anticipated, hindering the scalability of your application. Implicit conversion occurs when the data types of SQL Server columns differ from those presented by the parameter data types of the JDBC driver. Typically, SQL columns are configured with varchar(x) to conserve space compared to Nvarchar(x), while the JDBC driver defaults to transmitting strings as Unicode.

Preventing Implicit Conversion with JDBC Driver

You have two options to choose from based on ease of implementation:

Change the underlying SQL Server column types to align with the parameter datatype. However, this may not be ideal as Nvarchar occupies more space, and altering SQL column types entails significant design changes.
For applications utilizing JDBC, utilize a driver connection property known as “sendStringParametersAsUnicode.” This setting determines whether strings are sent to SQL as Unicode parameters or not. It’s the recommended option. If your SQL column datatypes involved in implicit conversion are varchar, set the value to false.

Once this is implemented, check the query plan again. If the value of the “sendStringParametersAsUnicode” setting is false, the parameters presented by the driver will show up as follows:

(@P0 varchar(4000),@P1 varchar(4000))select col1, col2 from table1 where col1 = @P0 ….

As the underlying SQL column types are also varchar, there is no implicit conversion, leading to improved performance and reduced CPU usage!

You can find a list of all the JDBC driver settings here. 

Feedback and suggestions

If you have feedback or suggestions for improving this data migration asset, please send an email to Databases SQL Engineering Team.

​Microsoft Tech Community – Latest Blogs –Read More