Prompt Engineering with Microsoft Copilot

Check what M365 Copilot license you have?

I have an Enterprise license, which allows me to create M365 apps and share them. I can also consume M365 apps shared with me for free.

Prompting Microsoft Copilot  

(Prompt engineering is a stupid name for search using AI)

Prompting is asking the copilot to give you information.  I advise using four parts to cover in your prompt> 1. goal 2. context 3. source 4. expectation, I remember it as "GCSE prompting".

1. Goal - what do I want, e.g., tell Copilot what we want

I want tactics for pricing my SaaS products

2. Context - Why do I need it

e.g., this is a new product in the B2C space

3. Sources - optional - ask from specific resources

e.g. provide my company stats and ask to compare to my market (from the LLM)

4. Expectations - Table of info, summary, or even an image(maybe not)

M365 Copilot app. 

There are tons of options to help with prompt engineering, the key is to give it clear instructions as shown using the the "GCSE approach" mention above.

Microsoft Copilot is integrated with Office Applications

Apps that M365 Copilot embeds with, if you have the M365 licence, include: 

1. Word, 2. Excel, 3. PowerPoint, 4. Outlook, and 5. Teams

1. Word

Word Copilot is part of the M365 Copilot branding.  Generates scaffolding/first draft.

2. Excel

Use in Excel with your own data - allows easy query using English/natural language.

3. PowerPoint

Draft a presentation using org themes based on prompts. You can also use Copilot to add images you create using Copilot (DALL-e).

My AI Posts

Microsoft Copilot Studio 2025 Simple Notes

Artificial Intelligence as a mega trend

Microsoft's Copilots Explained as the naming kills me

Prompt Engineering with Microsoft Copilot (this post)

AI model Comparison

Ignite 2023 - Keynotes - big push to AI Summary

Extranet Authentication Options for SharePoint 2013

Overview: Most large enterprises using SharePoint have implement Extranet solutions and these vary in complexity greatly.  Many implementation I have seen have morphed into bazaar solutions generally due to the tactical solutions implemented over time and were not caused by poor architecture.  It is the nature of these projects to get something out and with the rapid change in authentication over the past 5 years tons of business have landed in complex scenarios.

Office 365 has grown quickly and using Office 365 is generally a good idea however a lot of organisations still are resistant due to a variety of concerns such as regulatory compliance and trust.  Microsoft is definitely removing these barriers and I'd lean towards hosting the SharePoint Extranet in the cloud in the majority of situations.  The biggest barriers to moving to the cloud are Executive level buy in followed by senior IT folks that are bias to sticking to what they knew 10 years ago.   So a lot of the change is around education and providing a clear road-map.  The biggest technical hurdle will be around identify management.

Pretty much every organisation I deal with used Active Directory and then you may have a Federation Service normally ADFS.  You may have you external users in the same AD, a dedicate DMZ AD, or any other user directory including SQL or other LDAP provider.

Using Office 365/SharePoint Online I need to get both my internal and external users to be work with Office 365 and depending on the client setup I need to work thru both scenarios and think about the ramifications.

Note:  Ramifications are: resetting user passwords, does search work for all users and where does the data reside.

Possible Options:

• AzureAD - Azures ACS for user accounts
• Federated Identifies - use ADFS and build trust with ACS, identity and password is under our company control
• AD sync to AzureAD - Think DirSyng, tooling is ADConnect

On an on-prem. SharePoint farm, the following Authentication methods are supported at the Web Application Level:

1. Classic (Windows (Basic/NTLM/Kerberos)), 
2. CBA - Claims Based Authentication backed by either Windows Claims (Windows (Basic/NTLM/Kerberos)) or SAML Claims (ADFS or SiteMinder or Ping or ThinkTexture, ....)
3. FBA - Forms Based Authentication, and 
4. Anonymous (none)

Notes:
http://www.sharepointeurope.com/blog/2015/10/identity-management-in-a-saas-based-world

PS for Office 365

http://onlinehelp.microsoft.com/office365-enterprises/hh124998.aspx
http://technet.microsoft.com/en-us/magazine/hh750396.aspx
http://blog.powershell.no/2011/05/09/administering-microsoft-office-365-using-windows-powershell/

Rene Modery gave me some useful information on Office 365 namely you can manage Exchange Online but not SPO using remote PS. 

You can also use PS to manage information around accounts for Office365 which in effect is used by SPO.

MSOCAF

Overview: Microsoft SharePoint Online Code Analysis Framework (MSOCAF) is used by companies or people writing custom code solutions for SharePoint online to help them validate the code meets minimium coding requirments to be deployed to SharePoint 365.  Using MSOCAF code on a local SharePoint 2010 farm can be used evaluated the custom code before it is submitted to MS for approval on SharePoint 365.  Additionally, MSOCAF can submit the custom code to SharePoint Online and perform roll back functionality.

Using MSOCAF:

Installed MSOCAF applicationb on my development machine. 

Opened MSOCAF > Analyze



More Info:
http://blogs.msdn.com/b/rmeure/archive/2011/05/13/want-to-have-sharepoint-code-approved-by-microsoft.aspx

Writing solution validators  -http://msdn.microsoft.com/en-us/magazine/ee335711.aspx

How is SharePoint selling - a consultancy services roadmap

Overview: SharePoint is being taken up very quickly but it's a difficult market to measure.  A figure I heard at a conference a few months ago is that for every $1 spent on licencing generates $6 in consultancy.  I don't know this ratio was determined but if the number of licences being sold is on the up, it follows there will be a great deal of consulting services needed.

Most organisations I have dealt with use SharePoint to a very limited extent.  It has a lot more to offer than clients are taking up.  Intranets, file server replacement and collaboration are the main impetus for using SharePoint.  My feeling especially with SharePoint 2010 will be a shift toward better integration and using SP as a development platform.  Office 365 plays into this consultancy business also.  The main issue will be with setup/on site installations taking a hit however there still will be a need on site installations but more companies will choose SharePoint as a service and this is only a positive that results in more people taking to the product.

The companies affected will be the hosting companies as they will loose a lot of there sales, Azure will also affect them.  They have been loyal customers of MS for years and unless they change their offering to be more consultancy service based they will take a huge hit.

Anyway some quotes to show how SharePoint is selling:

"SharePoint licenses have surpassed the 100-million mark and more than 17,000 customers use SharePoint." Microsoft Technet 9 Feb 2011.

"Microsoft’s fastest selling server based product" is a phrase often banded about not sure what this metric is but it sounds good.

References:
http://blogs.technet.com/b/office_sustained_engineering/archive/2011/02/09/1office-2010-and-sharepoint-2010-momentum-amp-service-pack-1-update.aspx

Mapping internal users (LDAP) to the cloud

Overview: Steve Plank has a great video on "How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud". 

To get your internal ADFS users to authenticate in the Microsoft cloud (Azure and Office 365), you do need ADFS 2.0.  The claims based authentication that can be setup in SharePoint 2010 is how Office 365 and AZURE will authenticate AD users. 

You users will access SP2010/MS Online365/AZURE Web application using their browser.  The end application sends the browser a response redirecting them to the MS Federation Gateway (MFG)/App Fabric/STS web service (SP2010 on site editions), this in turn passes the users browser onto ADFS.

ADFS generates the user a SAML token and the are redirected to the MFG, MFG in turn generates it's own SAML token containing it's claims and the browser is redirect back to the originally requested web application.

For a user trying to access SharePoint Online from their internal network, you can see the user makes several requests to different points along the chain however the key result being the user get securely authenticated against you internal Active Directory (AD).
Steve Planks video is easier to follow than this post but it's worth understanding the process as it applies to Azure, SharePoint claims based authentication and Office 365.  This coupled with custom LDAP providers results in a consistent manner to handle authentication in the cloud using you internal LDAP directory.

Below is an animation describing the process whereby a user is authenticated on their internal network and then they use SharePoint Online (Office 365).

More Info:
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx?wa=wsignin1.0

Settingup ADFS for SharePoint Reference: