31 January 2018

Publish a Shared Calendar | PowerShell | Office 365

I recently needed to publish a Shared Calendar (i.e. Shared Mailbox's Calendar) to the internet, so it could be embedded into a website.

Whilst I'm sure we all know how to publish our own calendars, publishing a calendar that's shared to you is a little bit more difficult.  It's not as simple as just going into OWA and then publishing from there, or using Outlook.  This needs to be done using PowerShell.

1. Sign into Office 365 | PowerShell

2. Enter the following:
Set-MailboxCalendarFolder <mailboxname>@domain.com:\calendar - PublishedEnabled $True

This will then publish the calendar you've just defined in bold to the internet.  Now you will need to get the URL to access this. 

3. Enter the following:
Get-MailboxCalendarFolder <mailboxname>@domain.com:\calendar | fl

You will then get the following output:

RunspaceId           : 0f40e5da-5712-4043-8bbc-fb11049c0307
Identity             : calroom1:\calendar
PublishEnabled       : True
PublishDateRangeFrom : ThreeMonths
PublishDateRangeTo   : ThreeMonths
DetailLevel          : AvailabilityOnly
SearchableUrlEnabled : False
PublishedCalendarUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com
/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.html

PublishedICalUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com
/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.ics

IsValid              : True
ObjectState          : Unchanged


The URL for accessing the calendar is highlighted in yellow above.

Also pay close attention to the three items above which are highlighted in blue.  You will most likely need to change these from ThreeMonths to OneYear, and also change the availability to reviewer if you'd like the public to actually see the contents of the calendar.

09 January 2018

Reset NTFS Permissions | Export & Import Existing Permissions

I recently encountered a newly installed File Server which had some busted NTFS on it.  The file permissions had been copied over from the old File Server, and whilst they looked like they applied well, it was causing some issues accessing files etc.

I decided it was time to completely refresh the permissions on all the folders and sub-folders, to ensure that they applied correctly.

To do this, there's three steps which need to be taken.
  1. Export the existing NTFS permissions
  2. Reset permissions
  3. Restore old permissions
This is actually quite a simple task to do, and can be done by using ICACLS.  The following guide will explain how this can be done. 

1. Open PowerShell as Admin (you can also do this within an Administrative command prompt)
2. Run the following command:
icacls C:\TEMP\* /save "C:\Temp\AclFile.txt" /T /C
The part in bold is the 'source' of your NTFS permissions.  Selecting "/T" at the end ensures it goes through all the sub-folders as well to copy the permissions of them.

3. Run the following command to reset the permissions:
icacls C:\Temp\* /reset /T /C /L
The part in bold is the 'source' of your NTFS permissions.

4. Restore the permissions by using the following command:
icacls C:\Temp /restore "C:\Temp\AclFile.txt" /T /C

The part in bold is the 'target' of your NTFS permissions.

Note: before doing anything changes to permissions on a File Server, make sure you have either a working backup, or you've recently snapshotted the server. 


/T - Traverse all subfolders to match files/directories. This will apply permission changes to all subfolders whether or not they are set to inherit permissions from the parent. On very large directory structures this may take some time as the command has to traverse the entire tree. /C - Continue on file errors (access denied) Error messages are still displayed. /L - Perform the operation on a symbolic link itself, not its target.

02 January 2018

Issues Updating Print Drivers | KB3170455

Recently a client of mine updated their print drivers on the Print Server (through Print Managemnet).  Users suddenly had issues printing, where Word would say "Driver Update Required".  When a user would go to right-click on the printer and click on "Update Driver", they would get essentially a UAC prompt asking whether they trust that particular printer:


When they click Install Driver, it looks like it's installing and then it just falls back to the same message.  It looks like there's an endless loop where users can't print because of the driver update requirement, but they can't install the driver either.

These printers are deployed through Print Management and are deployed via GPO.  There are Point and Print restriction policies in place as well to remove any warnings or UAC prompts for installing new drivers, or updating drivers:


In theory, this should mean that there's no warnings and the drivers should just update.  I've had a look on the workstations and they're applying the policy correctly and the changes are there, so it's not an issue with applying the actual GPO.  With this in mind though, the warnings are still showing up and the drivers can't be updated.

When running the troubleshooter, it asks whether you want to install the updates with elevated privileges.  When doing this, it works fine.  After a lot of troubleshooting, this ticket was actually escalated to Microsoft support to look into this.  

They confirmed the following:

There was a Windows Security Update recently released which targeted the security of printing.  This was KB3170455 and this was the culprit!  Essentially what this update does is require drivers to meet certain criteria before they can be used.  The criteria is the following:
  • Package aware
  • Digitally signed
  • Catalogue print drivers

Apparently the official drivers we had downloaded from the Canon website did not meet this criteria.  Uninstalling this update has resolved the issue for all users.  

At the time of writing this blog, there is no official word from Microsoft acknowledging the issue caused by their security update other than what the support technician has told me, but they have confirmed that since the update, there have been a large number of support calls raised to their help-desk.


There's currently only two options to get around this:

  1. Download another driver that meets the criteria
  2. Remove the Windows Security Update from all servers and workstations
Note: if you are a small enough company, you can work around this by installing the driver update with elevated privileges.