OneNote Screen Clipping Shortcut after Windows 10 Creators' Update

Windows 10 Creators' Update may be many things to people who intend to... ah... create. But at least for IT folks, especially sysadmins and engineers, one thing is definitely going to get on your nerve.

You might have gotten a rude shock when you realize that Windows+Shift+S shortcut to send screen clipping direct to OneNote no longer works. Instead, now it merely sends the screen clipping to the clipboard. Cool feature, at least for them creators. But why would I want to have to bother with an extra step of pasting from the clipboard when I can send the whole batch of screenshots directly into OneNote?

Here's how to solve it. Get into regedit and create this new DWORD key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\OneNote\Options\Other\ScreenClippingShortcutKey 

Let's just set the value to 41 (hex ASCII code for the letter 'A'), now the shortcut key for screen clipping will be Windows+Shift+A. I chose A because it's next to S, so not much finger-relearning needed, but you can set it to any character on the keyboard.

After the registry change, somehow the UI still shows the old shortcut, but Windows+Shift+A is indeed the shortcut key to use when taking a screen clipping to OneNote.

For more options, have a look at this site:
http://www.winhelponline.com/blog/onenote-screen-clipping-shortcut-key-change/

Complex properties from Get-ADUser

If you have every tried to export a list of AD Users along with their ProxyAddresses into a CSV file using Get-ADUser, you'll understand the pain of using powershell sometimes. Here's a quick example:

"DistinguishedName","Enabled","GivenName","Name","ObjectClass","ObjectGUID","proxyaddresses","SamAccountName","SID","Surname","UserPrincipalName"
"CN=jondoe,DC=contoso,DC=com","True","Jon","jondoe","user", "00000000-000-0000000", "Microsoft.ActiveDirectory.Management.ADPropertyValueCollection", "jondoe","S-1-5-21-00000-00000-0000000-00000",,"jondoe@contoso.com"

The problem is while most attributes like DistinguishedName, Enabled, GivenName, etc. are simple text value, ProxyAddresses shows up as an ADPropertyValueCollection. Showing me its type does not help.

Here's a quick and dirty way I use to address this issue:

Get-ADUser jondoe -Property ProxyAddresses | select Name,UserPrincipalName,@{n="ProxyAddresses";e={$_.ProxyAddresses -join "|"}}

You can change the "|" character to anything you like, but you get the idea. It works just like magic!

Fine-Grained Password Policy and non-expiring Passwords

The world is moving towards non-expiring passwords. Even Microsoft themselves seems to agree. Well, we came out with a nifty way (IMHO) to implement this in our organization. Firstly, we kept our default domain password expiration policy, then we set up fine-grained password policy and apply it to normal user account. The FGPP will lift the password expiry, and put in account lockout rules. This way, we can ensure that other special cases will get applied the default domain policy and have passwords expire as usual.

So all worked well, except for OWA, which still shows password expiry date based on default domain policy. This means that users will be bugged to change their passwords, when their passwords will not actually expire anyway.

There's no real solution for this. Even Microsoft themselves acknowledged this and offered a few workarounds, but those aren't really practical. One of their workarounds was to disable OWA's password change feature. This is not ideal, but still acceptable, so we decided to go with that.

But the problem doesn't stop there. EWS has included a new function in its API since 2010 SP1, GetPasswordExpirationDate, which also has the same behavior. As a result, all Mac Outlook clients (and any other client making use of this EWS call) will keep bugging our users with password expiry notification.

We still have no solution, but it's good to know the technical details.

Lync 2013 Client With OCS Registry Hack, The PowerShell Way

I have been formatting my desktop quite a bit these days. And I realised that each time I format, I need to do all the usual stuff and hacks to get things working the way it did. One of them, is of course, the registry hack to get Lync 2013 to connect to the OCS server at my company.

So I decided to do this the powershell way. Turns out it was just 2 really simple commands:

New-Item HKLM:\SOFTWARE\Policies\Microsoft\Office\15.0\Lync -Force
New-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Office\15.0\Lync -Name DisableServerCheck -Type DWord -Value 1

Do remember that you have to run PowerShell with Administrator rights.

UPDATE: Now that skype for business 2016 is launched, it's time to update the script a little. Use this one below instead.

New-Item HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Lync -Force
New-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Lync -Name DisableServerCheck -Type DWord -Value 1

Get-ADUser -Filter crashes suddenly after 256 objects when filtering by Created (or other DateTime fields)

Today, I wanted to find newly created accounts in an OU. So I decided to run a simple Get-ADUser command:

$cutoff = [DateTime]"12-Aug-2014"
# Make sure we get the TimeZone correct. This is one of the reason I prefer to use the PowerShell Filter rather than the LDAPFilter
$cutoff = [DateTime]::SpecifyKind($cutoff, [DateTimeKind]::Local)
Get-ADUser -Filter {Created -gt $cutoff} -SearchBase "OU=Department,DC=contoso,DC=com"

Simple as that right? well, no!

It returned up to 256 accounts, and then generated an exception:

Category Info: Not Specified: (:) [Get-ADUser], ADException
FullyQualifiedErrorId: ActiveDirectoryServer:8256,Microsoft.ActiveDirectory.Managment.Commands.GetADUser

This is obviously a bug, and until MS fixes it, we have to use the workaround instead:

Get-ADUser -Filter {whenCreated -gt $cutoff} -SearchBase "OU=Department,DC=contoso,DC=com"

Both "Created" and "whenCreated" are supposed to point to the same AD attribute, why one works and the other crashes is beyond me...

AD FS 2.0 and Shibboleth 2

Well, the story starts like this. Somehow my boss decided that we should stick to Microsoft technology when it comes to identity federation. And it so happens that AD FS 2.0 now supports Shibboleth albeit with some really get-your-hands-dirty manual tweaks. One of the major pain points is that we need to hand-edit the ADFS metadata XML file to be presented to the Relying Party. (If all these sounds like Navajo to you, google up Shibboleth, it's an interesting technology)

Anyways, time passed, and it's almost a year into our production deployment. Now, due to the yearly certificate rollover, we have a need to rebuild the Shibboleth XML metadata for our Relying Party. Having to do this once a year is just too risky for a production system, so I decided it's time to put my ASP.NET skills into good use again.

Well, the result was a simple MVC web application that loads the auto-generated metadata from ADFS default URL location, go some really hack-ish massaging to it, and spit out a well-formed XML metadata that Shibboleth 2.x SPs will happily parse. 

Also, this is the first time I'm using codeplex! ^.^

You can download the app package and source code here:
http://a2s.codeplex.com

Junos Pulse native VPN client on Win 8.1 (Advance configuration)

I just discovered another new thing about connecting to juniper networks SSL-VPN.

So the company I work for has multiple "sign on policy path" for our vpn, as the official documentation from juniper puts it. Normally, everyone is expected to go to the full official URL in the browser to connect to the VPN. Connection will require ActiveX, Java, and the right browser to start working.

Windows 8.1 came with a native VPN client, which was a good thing. But unlike the client in iOS, the server field does not take in a url. Hence, I can only connect to the default VPN path, but not to https://vpn.contoso.com/admin

Turns out, the way to do this is only through PowerShell. So let's get straight to the code:

$xml = '<pulse-schema><uri>/admin</uri></pulse-schema>'

$sourceXml = New-Object System.Xml.XmlDocument

$sourceXml.LoadXml($xml)

Add-VpnConnection -Name 'AdminVPN' -ServerAddress 'vpn.contoso.com' `

    -PluginApplicationID "JuniperNetworks.JunosPulseVpn_cw5n1h2txyewy" `

    -CustomConfiguration $sourceXml -SplitTunneling

The "SplitTunneling" is useful is you only want to route VPN network traffic through the adapter. For my case, the admin VPN of my organization doesn't have a gateway to the internet, hence split tunneling is necessary.

Turns out there are more configuration options for the XML. Here are those that are supported: