I play with and use Windows 10 Insider builds but don’t often blog about them – there’s plenty of other people that do that already. However, I saw this notification come up which seemed very useful; Clipboard History!
Something I’ve been wanting for many years. I currently use Ditto which I recommended in another writeup of free sysadmin tools for TechTarget. However, if a native solution does enough for me I’d rather use that – I’m on that many different systems and devices, having non-native apps is a pain that I’m not going to bother with.
I might be a bit late to the party – on May 9th 2018, Build 17666 was announced with this feature. I’ve had a quick play and like it… so how does it work?
First, go into Settings > System > Clipboard. You’ll need to toggle the ‘Save multiple items’ to ‘On’. This is probably good being off by default, I can imagine complaints about Microsoft tracking what people do or someone finding something in the history that another person did.
Once that option is on, you can use Windows Key + V to bring up the clipboard history window:
It will be blank at the start, unless you’ve used the clipboard since enabling the feature. Text and images are both supported which is great! Selecting the history item will immediately paste it as well as put it onto your clipboard. It’s basic but does the job
On top of this, there’s also a ‘Sync across devices’ option for the clipboard history. You can enable that in the same settings area, and your clipboard will be available from all devices that support it. Right now that seems to only be Windows 10 on this insider build or newer, but I’d expect it to go further to mobile devices when released properly. This is a great way to send a small bit of information such as a long URL from one device to another.
However, if you use a password manager where you copy and paste usernames and passwords from, they’ll get added to this history also. If someone were able to gain access to this history, it could be a quick gateway to accessing a lot of your other stuff – so use multi-factor authentication wherever you can.
Still, it’s a great feature albeit simple – it’s nice to see Windows 10 getting loaded with different mini-utilities that add to it’s usefulness, while leveraging a centralised Microsoft account to keep and sync information.
I don’t do too much with SQL, but this one got me for a while, so here’s my story on SQL Server Configuration Manager Aliases.
I had a particular server that couldn’t connect to a specific instance on SQL on another box. Other servers appeared to be fine, but each time SQL Server Management Studio was run and attempted to connect to servername\instancename, it would instead connect to the default instance.
It didn’t matter who logged onto the server either. It would never connect to that secondary instance and I couldn’t work out why.
After much digging and testing, I resorted to reading through forum threads on Google searches, hoping for an idea. What I eventually found was the existence of SQL Client Aliases. These are like hosts file records – hard coded results for connecting to a specific server:
In Sql Server Configuration Manager, you can define an alias for what you’re connecting to. Servername\instancename could map to serverb\instancename or servername\instance2 – this is great when doing testing and wanting to point a server at a different SQL database or instance without changing a bunch of settings.
However, the other catch is the port specified. In the above example, the default SQL port 1433 is used. Makes sense, but each instance uses it’s own port, or uses a dynamic port. I soon discovered that if you try to connect to a SQL instance and have a port defined, the SQL instance you actually connect to is whatever is listening on that defined port.
An easy thing to find if you know where to look for it, and now I do. Hopefully this helps others who come across a similar scenario!
There’s currently an issue with configuring Conditional Access via Azure Active Directory. There’s an open ticket with Microsoft Support, with no ETA at the time of writing.
The issue: When trying to configure a new policy for Conditional Access against an Azure Active Directory application, the ‘New’ page gets stuck loading. I’ve tested this on multiple browsers, tenants, internet connections, computers, and had Microsoft support confirm.
The path to doing this is from the Azure portal – Azure Active Directory > Enterprise Applications > choose your application > Conditional Access > New policy:
The Workaround: Thankfully it’s not a showstopper, as there’s another way to get to Conditional Access and it works fine. Instead of going via a specific app first, you can just go via Azure Active Directory > Conditional Access > New policy. Also Azure Active Directory > Enterprise Applications > Conditional Access > New policy works, it’s just an extra click to the same screen.
Points to take note of – if something’s broken, try accessing the same function from a different route of click-through links and it might work another way. Also, log these issues with Microsoft Support as overall the support is pretty good and often the issue won’t be anything to do with you. Test different scenarios wherever possible too, and also asking the question on Twitter can get some extra attention!
“I’ve lost a document and can’t find it!” is a common phrase that nobody likes to hear. Most people are working in Microsoft Word for their documents, and although it has a bunch of nice features for autorecovering lost work, it doesn’t cover all scenarios.
There’s even a new feature which autosaves your work as you go; as long as the document is in SharePoint Online or OneDrive for Business.
However, it’s still easy for someone to accidentally close a document and say ‘no’ to saving changes, or other scenarios where documents get overwritten with the wrong information. A document management system (DMS) with versioning (such as SharePoint) can help, but I’ve yet to hear of a company that has 100% of their documents at all times in their DMS!
Anyway, after seeing many scenarios of lost work, I thought there might be another method I can implement to help capture lost data. Microsoft Word’s Autorecover function does work quite well, in keeping an ASD file updated at regular intervals (10 minutes by default) which are saved in C:\Users\username\AppData\Roaming\Microsoft\Word\ (by default). I changed this to 5 minutes rather than 10:
Autorecover will update an ASD file in this folder for each document you have open, on the frequency configured above. That file can get closed or lost depending what the user clicks (again, closing and not saving a document is a scenario that will lose the ASD).
My idea was to back up these ASD files also on a 5 minute interval, giving another avenue to restore lost documents. Because the AutoRecover starts at a random time, a script running every 5 minutes would also start at a random time, and together there’d be a 5 to 10 minute window on copying out the backup files, which isn’t a huge amount of work to lose if someone had been working for hours.
Here’s the PowerShell script I wrote. It first sets a few variables that can be configured, then does a cleanup of previous backups. If they’re > 2 days old, backup folders are purged or we’d have an ever growing amount of backups. The 2 day value in (Get-Date).AddDays(-2) can be changed.
Then, it runs a filecheck to make sure there’s ASF files to back up. If not, the script breaks. If files exist though, it then creates the Backup folder, creates a sub folder based on the date/time and then copies the ASD files into that folder.
The format of the folders is set at the very start of the script, and again can be changed to a different format if you prefer.
(note that the File copy section was taken from here). Save the above as a .PS1 script and you’re good to go.
That worked well after a lot of testing, but the next problem was getting it to run on everyone’s computer. Using a Scheduled Task means we can configure it to run however often we like and whenever we like, as well as being able to push out the task via Group Policy. However, you can’t run PowerShell scripts silently just by running a PS1 file when triggered from Scheduled Tasks.
There is a great workaround here which uses a VBS file to then trigger the above PS1 script. the VBS component itself runs silently which in turn runs the PS1 script silently. Here’s a copy of the script in case the link goes dead, but please read the original link for more details:
Set objShell = CreateObject("Wscript.Shell")
Set args = Wscript.Arguments
For Each arg In args
PSRun = "powershell.exe -WindowStyle hidden -ExecutionPolicy bypass -NonInteractive -File " & arg
The final catch is then opening an ASD file when you want to recover something. To open a recovered file, in Word go to File > Info > Manage Document > Recover Unsaved Document (if the Info link is greyed out, open a new blank document first). If you had to navigate away from the default location it shows to open the ASD file, you will probably see this error:
As pointed out here, for some reason Word doesn’t like opening the file unless it’s in the special ‘UnsavedFiles’ location. Luckily you can just copy the ASD file into this folder (which by default is C:\Users\%username%\AppData\Local\Microsoft\Office\UnsavedFiles” ) and then open it as per the above method.
Keep in mind, both the PS1 and VBS files also need to be available to the user, which you may want to also push out by Group Policy. Just make sure the file called by the Scheduled Task exists, or the users will see an error saying the file can’t be found, every single time the script runs.
Update 16th July 2018
I’ve adjusted the script slightly for use in a terminal server environment (RDS or Citrix). The scripts are seperate – yes a master one could be created, detect if it’s a client or server, then run the appropriate parts, but I haven’t done that :)
The only real change is getting the list of logged on users from a broker. I could filter these out to only grab the users on the local box but the script runs within a second anyway and shouldn’t find or do anything if the user profile doesn’t have any backup files.
Going from Exchange On-Premises to Exchange Online can be a bit of a learning curve. One of the changes is having to worry about licensing a lot more; on-prem you can have as many service accounts as you need (e.g. a ticketing application may need access to a mailbox to send and receive emails, or to create IT Helpdesk jobs from emails) and you’re good to go.
With Exchange Online however, every single account needs to be licensed. As per Microsoft’s FAQ on the topic:
How is Exchange Online licensed?
Exchange Online is licensed via a subscription model in which each user needs a User Subscription License (USL). Three types of subscriptions are available: Exchange Online Kiosk, Exchange Online Plan 1, and Exchange Online Plan 2. These subscriptions can be purchased on their own or as part of an Office 365 plan that includes SharePoint Online, Skype for Business Online, and Office ProPlus.
Here’s a breakdown of all the license options for Exchange Online, and what features each license has.
Your normal users are probably going to have some sort of business package applied to each user – one of the most common is Office 365 Enterprise E3, but generally not value for money for a single purpose service account.
The Exchange Online Kiosk plan is the cheapest, but limited. Also note that there’s the Office 365 F1 plan which includes Exchange Online Kiosk, but again is a more expensive package with features you probably don’t need. Although this license can also be used to access another mailbox, there are many limitations such as “Exchange Online Kiosk does not provide access rights for utilization with on-premises servers.” and the ability to access the mailbox using Microsoft Outlook. It also can’t use Exchange Web Services (EWS) which is one of the more modern ways that a developer will read or manipulate emails.
Exchange Online Kiosk has the brief description of “Basic messaging and calendaring plan with Web email and POP access.” If you purely want to send emails via SMTP using Office 365’s SMTP connector, then this is what you need.
For most other functions, you’ll need at least Exchange Online Plan 1. This is the next cheapest option, and gives you a standard fully working Exchange Online account with a fully functional mailbox.
There is another option around all this; if you’re happy to run Exchange Hybrid but have all your mailboxes in Exchange Online, you’re entitled to a free Exchange Server license. With that in place, you can use SMTP relays to allow your on-premises accounts to use that connecter without a license, and have that relay back to Office 365. It’s also possible to do ignoring Exchange Hybrid if you build your own IIS server and SMTP Relay. Both of these options are great for devices like printers that may be sending emails anonymously, or to avoid changing configuration of all your devices with the new Office 365 SMTP server smtp.office365.com .
As you’ll need to do license management and probably be looking at month to month charges, it’s important to understand licensing and allocate in the most cost effective way. Of course, all this may change so please check official Microsoft documentation to ensure you’re getting what you need.