Tuesday, August 4, 2015

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

Tuesday, August 12, 2014

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...

Monday, June 30, 2014

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

Friday, May 30, 2014

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:

Tuesday, April 8, 2014

PowerShell, Task Scheduler, and Start in options

I just realised after lots of twist and turns that when scheduling a powershell job, the Start in value will not work if I just put the Program as "powershell.exe". If "Run with highest privileges" is checked, the working directory of your script will just be "C:\Windows\System32" regardless of what value you put in Start in. Just like it would if you launch powershell as administrator from the start menu. I haven't tried this, but I guess if it's not checked, the working directory should be %HOMEDRIVE%%HOMEPATH%

To solve the problem, just change the Program value to the full path. In my case, this is "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe". Quite a handful to type, but it's the only way I managed to get it to work so far. If there are any better suggestion, I'd be glad to hear.

Monday, December 9, 2013

Of PowerShell, dotNET, and unblocking DLLs

I've been trying like crazy to get my System.data.SQLite to load into Powershell. I tried all the versions, checked and double checked versions and dependencies...

At the end, the solution was super simple. Right-click, properties on the downloaded zip package, and click UNBLOCK. Damn you security feature, wasted half a day just figuring this out!

Friday, May 3, 2013

Changing the Primary and other emails for DirSync Office 365 users (with no exchange on premise)

OK, the idea is that if you are using DirSync for user objects on office 365, there is no way to change the SMTP address on office 365 portal. You can't even do it on the exchange management console, and you'll get almost the same luck if you try using Remote Powershell to O365 or even Exchange Management shell.

After hunting all around the community forums, I finally found a few good way we can do this via powershell (after all, you don't want to go mess with ADSIEdit if you're in an enterprise environment, having hundreds of accounts to provision or modify each day).

Simple method 1 (only set Primary Email - SMTP):
Using Remote PS, run the following command
Set-Mailbox user -WindowsEmailAddress user@domain.com
This is pretty good, as it just sets the primary email to what you want it to be, and forget about everything else. But if you are one who have exchange on premises, the "ProxyAddressess" field in your on premise, federating AD will overwrite that. So this is the only way to modify it:
Get-ADUser $sAMAccountName -properties ProxyAddresses | %{$_.ProxyAddresses += @('SMTP:primary@domain.com', 'smtp:secondary@domain.com'); Set-Aduser -Instance $_ }
For more complicated requirements, you may have to parse through the ProxyAddresses array to remove SMTP fields you don't want, add in smtp fields you want, etc. Maybe if I have some extra time in the future, I shall write a little helper script to do just that. I may even have a need to write such a script in the future, who knows ;-)