Tag: Tips

Apply default calendar permissions in Office 365

Something that’s often frustrated me as an O365 Administrator is the lack of ability to craft and apply default calendar sharing permissions in Office 365. Sure you can create sharing policy for external organisaitons, but what about all your internal users? This is pretty standard stuff for internal collaboration, so why can’t we do it via the Admin Portal?

Like most things though, if you can’t do it via the UI, you can probably do it via PowerShell. Guess what.. you can do this too..

I love PowerShell so I’m ok with this, but on the off-chance you’re less excited by the ‘shell approach, feel free to steal this and claim it as your own (I don’t care – own it).

So first up, get your ‘Shell sessions sorted – if you’re already sorted here, skip to the next bit. If you’re not, check this out (I don’t tend to do this bit quite like other folks – mostly cos I’m lazy and don’t like typing in my username).

$cred = get-credential [email protected]
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $Session
Connect-msolservice -credential $cred

If you’re wondering why I’m calling an Outlook session and the MSOLService, that’s cos we’re going to cross both the Office 365 and Azure AD environments. Madness.

There are a bunch of blog posts out there that talk about how to apply permissions for a given user, but frankly that’s what the GUI is for, so why bother do that via PowerShell. I’m more interested in bulk application of permissions, so that’s what you’ll find below.

Let’s assume you have (like I do) a security group that includes all your users (or at least a big chunk of the ones you care about). And lets assume you want to apply the same set of standard calendar sharing permissions to all your users – so all staff can see the same properties of all other staff. That’s what this bit does…

Now, like many a lazy (pragmatic?) admin, my ‘all staff’ group is actually a set of nested groups – in my case, one for each of our global offices. Not an unusual scenario I suspect. So first thing I need to do is expand those out to their actual members. Let’s do that first. Note that if you are not using nested groups, you can skip this step.

<Group DisplayName> is the name of your ‘all staff’ group. This step will find all the groups that exist within your ‘all staff’ group.

$id = Get-MsolGroup -all | ?{$_.Displayname -eq '<Group DisplayName'} | select ObjectID
$groups = Get-MsolGroupMember -GroupObjectId $id.ObjectId | ?{$_.GroupMemberType -eq 'Group'} | Select DisplayName

Now that we have the list of actual groups in your main group, we’re going to iterate through each one, find the members, and set a given set of permissions for each mailbox. The syntax here is set/add-mailboxfodlermission -identity <calendar being impacted> – user <user being granted permission> -accessrights <specific access control>.

foreach ($grp in $groups){
$grpname = $grp.DisplayName

# Gets the object ID for the given group
$grpid = get-msolgroup -all | ?{$_.DisplayName -eq $grpname} | select ObjectID
Write-Host Iterating through $grpname

# Gets the members of the given group and returns their mailbox
$who = Get-MsolGroupMember -GroupObjectId $grpid.ObjectID | Select EmailAddress

# Iterates through each mailbox and sets permissions
foreach ($w in $who)
$eml = $w.EmailAddress
$cal = $w.EmailAddress + ':calendar'

# Assigns the 'Limited Details' permission (Free/Busy/Subject/Location) on the mailbox, for all members of the original group (eg. all staff in this example)
add-MailboxFolderPermission -Identity $cal -user <[email protected]> -AccessRights LimitedDetails -ErrorAction SilentlyContinue
# Assigns the 'Availability Only' permission (Free/Busy only) to the system 'Default' role.
set-MailboxFolderPermission -Identity $cal -user Default -AccessRights AvailabilityOnly -ErrorAction SilentlyContinue
# Removes any permissions for anonymous users
set-MailboxFolderPermission -Identity $cal -user Anonymous -AccessRights None -ErrorAction SilentlyContinue

This will step through each nested group, expand the members, and assign the permissions define above to each member. In addition it will set basic permissions for the system roles ‘Default’ and ‘Anonymous’. Feel free to adjust these to suit your purposes.

I confess, I’m being a little lazy here. What I probably should do here is apply some if/then/else logic to determine what the current sharing permissions are, to ensure only actual changes are processed, which would (massively) speed up the script, but I ran out of time to get the logic working (it’s more complicated than just a simple ‘where equals’ unfortunately). It’s on my backlog – I’ll update this post if (when?) I get it working.

Hope this is useful.

JB / TheGingerOne

What happens if you jump the gun installing SP2010 SP1

Quick post on what seems a common issue.

You apply SP1, reboot the server, and open Central Admin to see all the bright shiny bits in SP1.

But alas, Central Admin returns a 503 error. In services.msc you find most of the SharePoint services are not started – admin, timer, user code host, search. Oh no!

Fear not, it’s just a case of being too keen for the shiny. The last step of the upgrade is to run the SharePoint Config Wizard. This completes the upgrade process, starts your services, and brings you all that is shiny and new.


SharePoint column lookup and calculation limitations

List lookup columns in SharePoint are great. Easy to setup, simple to use, and powerful. But they have some limitations that can be frustrating.

Let me paint you a picture..

You have a SharePoint list that contains information about a customer entity (yes it should probably be in CRM, but lets assume you don’t have one) – fields like contact names/numbers, addresses, unique systems, notes, etc. Some of these fields are single lines of text, pull-down menus, yes/no radio buttons, multiple lines of text, you name it.

You have another list that relates to sales of products to customers. Unsurprisingly, you want to link a sale to a customer, and you want to leverage the power of lookup columns to make that a simple and seamless process.

Not an unrealistic scenario. Sure there are better ways of doing it with the likes of webservices into CRM or BCS connections into LOB databases, but they all involve additional systems, coding skills, and generally more effort. All things that aren’t always readily available.

By adding a lookup column type to the sales list you can allow a customer entity to be selected from your customer list. Where this gets handier is you can have the sales list pull other values from the customer list without adding extra columns. Awesome.

But… not all the columns from your customer list are available. Why not?

SharePoint can only perform a lookup of values from columns that contain a ‘text’ value, and then only if it contains a single line of normal text (ie. “Single line of text”, a “number”, or “date”). Any field that contains multiple lines of text, other lookups, or multi-select items won’t be available to you, as SharePoint will automatically hide any columns that it knows it can’t return.

This same restriction applies to using these column types in calculated columns, and there is a great post by Dessie Lunsford on getting around this limitation in terms of calculated columns which you’ll find here – http://www.endusersharepoint.com/2009/06/17/taming-the-elusive-%E2%80%9Ccalculated-column%E2%80%9D-referencing-multiple-lines-of-text-column/

The workaround involves creating your problem field as a “single line of text” column, then creating a second calculated column that references the first column name – eg. [=ColumnName]. You then delete the first column and recreate it with the exact same name but this time selecting your column type of choice.

While Dessie’s post deals specifically with referencing these columns via calculated fields, by dint of good fortune and SharePoint consistency, the same workaround fixes the lookup problem as well. Thanks Dessie!

This issue applies to all versions of SharePoint since 2007, including SharePoint Online (BPOS/Office365)

Working with Correlation IDs in SP2010

One of the most useful (from an Admin’s perspective) improvements in SharePoint 2010 was the introduction of Correlation ID’s to assist with diagnosis of errors. Unfortunately a lot of people I’ve talked to don’t use them because they don’t understand how.

I recently came across this post from Tobias Zimmergren that does a superb job of showing you several quick and easy ways to make these little GUID’s work for you.

In short…

get-splogevent | ?{$_.Correlation -eq "<GUID>"} | select Area, Category, Level, EventID, Message | Format-List

…will return the detailed log chain relating to that ID, in a human readable format. Handy.

And this..

FROM [WSS_UsageApplication].[dbo].[ULSTraceLog]
WHERE CorrelationId='<GUID>'

…in a SQL query will return much the same detail. I particularly like the suggestion of inserting this in a data-query web-part in Central Admin web-part. Super handy.

Removing server from SharePoint farm

It might sound obvious, but it is often the little things that catch out even the best of us at times.

If you’re in a situation where you need to remove a server from a SharePoint farm, then re-join it to the farm again (perhaps to resolve some sort of local corruption of the site config), make sure you manually check that all remnants of SharePoint farm membership are removed before you try adding it again. Normally SharePoint keeps a fairly tidy house and cleans up after itself well – but occassionally it leaves something behind, and this can wreak havoc on your environment if not picked up. Depending on which server role you’re dealing with in the farm, this could mean websites and/or application pools in IIS, databases, web application folders on the filesystem, or a bunch of other things.

This tripped up a colleague of mine recently – in this particular case the Security Token Service was for some reason not removed when the server was removed from the farm. When the server was re-joined to the farm, there were no errors, or issues that suggested there was a problem, but things started falling apart shortly afterwards.

How we located the issue was that the search functionality within a SharePoint site on the farm started returning those lovely generic SharePoint errors, and digging through the logs we found that old chestnut “Object reference not set to an instance of an object”.

Removing the server from the farm again, manually removing STS from IIS (including its application pool), then re-adding the server to the farm solved the problem immediately. Presumably there was some GUID under the hood that binds the STS to the farm, and as a result of the remove/join this GUID got out of sync with reality.

JB / The Daywalker

Ginger IT dude hanging out down in New Zealand, playing with technology since ages ago.

Currently Service Delivery Manager at Silicon Systems, formerly Skype for Business MVP, and generally into all things Microsoft (and a few things that aren’t).

When I’m not nerding out on technology, you can find me running ultramarathons, brewing beer, or in my woodshop building something.

On The Socials

Visit Us On LinkedinVisit Us On TwitterVisit Us On Facebook