Tagarchief: microsoft


Windows Phone “doesn’t support SSTP” as a VPN type, but using Microsoft’s own FieldMedic app, the following is revealed:

Description             : WAN Miniport (SSTP) #13
Interface Index         : 14
Type                    : 131
Media Type              : 12
Physical Medium         : 0
Operational Status      : Not Present
Interface Flags         : 0x1 = hardware
Speed                   : 0 b/s
Physical Address        : 10-2F-6B-xx-xx-xx
MTU                     : 0
Bytes Received          : 0
Bytes Sent              : 0
Rcv Packet Errors       : 0
Rcv Packets Discarded   : 0
Out Packet Errors       : 0
Out Packets Discarded   : 0

COMMON Microsoft!

My last Nokia was the world famous 3310.
The years must have been 2001 or something, and I used it for almost 2 years!

Now, my previous Windows Phone, the Samsung Omnia 7, was also already 3 years old (personal record!). And the end-of-support for WP7 was approaching.

Luckily, Microsoft announced the 930.
All I wanted in a high-end phone:

  • AMOLED, once you go black…
  • lots of RAM – 2GB
  • massive amount of cpu-power – quadcore @ 2.2GHz
  • big battery – 2420 mAh
  • wireless charging – cool gimmick
  • NFC – I really see this happening!

IN A PHONE (the world has gone mad)

Anyway, the thing works amazing!

Battery-life of almost 2 days IN USE.
Great screen, beautiful pictures, fast as hell, …
Fancy design and iPhone-like metal finish.


Go Nokia!


If you want pictures more of the phone:

Get-ScheduledTask | Where State -ne “Disabled” | Get-ScheduledTaskInfo | Select TaskName,TaskPath,LastRunTime, LastTaskResult,NextRunTime,NumberofMissedRuns | Sort-Object lastruntime

task running during screensaver

TaskName : RunFullMemoryDiagnostic
TaskPath : \Microsoft\Windows\MemoryDiagnostic\
LastRunTime : 13/03/2014 11:12:12
LastTaskResult : 2147943467
NextRunTime :
NumberofMissedRuns : 0

TaskName : WinSAT
TaskPath : \Microsoft\Windows\Maintenance\
LastRunTime : 13/03/2014 11:12:12
LastTaskResult : 0
NextRunTime :
NumberofMissedRuns : 0

TaskName : Idle Maintenance
TaskPath : \Microsoft\Windows\TaskScheduler\
LastRunTime : 13/03/2014 11:12:12
LastTaskResult : 0
NextRunTime :
NumberofMissedRuns : 0

TaskName : ProcessMemoryDiagnosticEvents
TaskPath : \Microsoft\Windows\MemoryDiagnostic\
LastRunTime : 13/03/2014 11:12:12
LastTaskResult : 2147946720
NextRunTime :
NumberofMissedRuns : 0

TaskName : Regular Maintenance
TaskPath : \Microsoft\Windows\TaskScheduler\
LastRunTime : 13/03/2014 11:12:12
LastTaskResult : 0
NextRunTime : 13/03/2014 15:21:21
NumberofMissedRuns : 0

Install it on your computer.

It’s just that nice extra barrier between Microsoft Windows and a whole lot of malware around.

In fact, Microsoft should just enable these settings by default, but apparently they’re afraid to do it…
(In some cases it can actually break applications. For example Skype has known issues with EMET…)


Because there still is a huge lack of documentation about Microsoft AD RMS, here some hints and tricks to use!

  • First thing: irmcheck! Go use it!
  • Always check ntsf acl permissions on the server side files asmx-files.
  • ConnectionString for SQL is located in registry
  • MSIPC (RMS client 2.0 in windows 8 and office 2013) caches in registry and %localappdata%
  •  REGISTRY:\Software\Classes\Local Settings\Software\Microsoft\MSIPC\<Server Name> \Template (HKCU or HKLM)
  • %localappdata%\microsoft\msipc
    Hint: you can delete huge file names with  “rmdir MSIPC /s” in cmd (for some reason it doesn’t work in powershell)success
  • Advanced troubleshooting on OSI Layer 7: fiddler! (enable https decryption) Really, put it in between! You’ll get some far more usefull error messages then “cannot connect to the server”, or “cannot use this feature without credentials”…
    Even better, go Wireshark (note: ssl mitm here…)!
  • The older MSDRM (RMS Client 1) puts everything in your %localappdata%\Microsoft\DRM . There you can find your user- & machine certificates, and templates.
    Regkeys under REGISTRY:\software\microsoft\msdrm
  • always check the IIS certificates! If there’s something wrong, nothing will ever work!

Please, open them up, they’re just XML-based, and contain a lot of information! For example, in the GIC-file you can confirm your RMS-location. Don’t bother trying to modify them, they’re hashed… But you definitely should check them for having :443 in their url’s (check this article)
GIC (Group Identity Certificate) = RAC (Rights Account Certificate)
CLC (Client Licensor Certificate)
CERT-Machine = SPC (Security Processor Certificate)

More about those 3 files in here

  • When you need to go deeper, use debugview (or something new: Trace Spy). This works for bot MSDRM and MSIPC
    Server-side and Client-side
  • Go and check Windows Event Logs. RMS Client doesn’t actually logs something there, but it can be a source of good information anyway!

After a few years of fighting with Lync2010 , we decided to stop using this service on premise and migrate everyone to the cloud/Office365!

For something as Lync, privacy and auditing isn’t that important (not yet), so we guessed we can trust Microsoft on this one…

  • First thing to do: create a trust between Microsoft and our on-premise AD.

This is done by implementing ad fs.
On top, you need to have an active “DirSync”, syncing your AD to the cloud.

To create the hybrid set-up with an on-premise Lync environment, and the “in the cloud”-office365 one, you’ll need the latest iteration of the Lync server software: version 2013.
So, we added the Lync 2013 servers to our 2010 deployment. And after some little hassles, everything started to work. (Single IP deployment, you can google around how to set it up)

You need a lync2013 edge and front-end, because we’ll need some specific features introduced in 2013.

  • Next: the Office 365 part.

Office 365 is a complete infrastructure as a service platform from Microsoft offering Sharepoint, Exchange,  Lync and some more Microsoft Services in the cloud. It’s pretty cool actually.
I’ve never been too fond of office 365: it’s cool, nice and cheap when everything is working. But when it start failing… You’re gone… AAAND you always have to mention the Patriot Act…

Anyway, since it’s February wave of updates, office 365 became even more functional!
It’s PowerShell support got an update, and now supports Lync Online cmldlets!

Before, you actually had to ask Microsoft to enable the PowerShell for Lync Online because it was in beta. Nowadays (since august), everyone gets it!
So, nice again 🙂

Msol-powershell doesn’t support a lot of cmdlets, but at least some essentials.

  • To be able to migrate a user, we’ll have some more requirements: on premise active directory tweaking and office 365 domain setup.

Of course you need to connect your DNS-domain to your office365 tenant (can be done easily using dns-verification)

Next, make sure your AD upn ( corresponds to your lync domain and your office 365 account. You can add the domain as a custom suffix in ad.
So, you’ll have an internal AD user, as sip-address, and the same as office 365 user (synced by dirsync).
Your lyncdomain doesn’t exactly has to be the same as your login domain, but hey, “why make it simple and functional if you can make it complex and wonderful?!”…

After that, you can fire up PowerShell!

Fist of all, you have to add Lync Online as an trusted host on your onpremise lync and you have to make your on premise Lync share the SIP address-space with Lync online
Use “Set-CsHostingProvider” here…

And then you can actually move someone between both environments! 🙂 (make sure the user has a office365 license assigned). Again, all can be done in PowerShell.

So, connect to your onprem lync and office365, and push your clients to the cloud!

$CSSession = New-PSSession -ConnectionUri https://onpremlync.contoso.lcl/ocspowershell -Credential $AdminUsername -ErrorAction SilentlyContinue
Import-PSSession -Session $CSSession
#exchange online
$ExSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $ExSession
connect-msolservice -Credential $cred
#lync online
Import-Module LyncOnlineConnector
$CSolSession = New-CsOnlineSession -Credential $cred
Import-PSSession $CSolSession –AllowClobber

get-msoluser -UserPrincipalName | Set-MsolUser -UsageLocation “BE”
Set-MSOLUserLicense -UserPrincipalName -AddLicenses CONTOSO:MCOSTANDARD
get-csuser | Move-CsUser -Credential $cred -target “” -HostedMigrationOverrideUrl “; -ProxyPool “onpremlync13registrar.contoso.lcl”