Some time ago we built a second ADFS farm at our datacenter. We knew we had to upgrade to v3 at some point, but wanted to keep our v2 farm intact so we could always do a rollback. We also wanted to use a new domain name for our brand new Windows 2012 R2 ADFS cluster, including the WAP proxies.
Setting all this up proved fairly easy, ADFS v3 was Continue reading ADFS v2 to v3 side by side migration for Office 365
Map your OneDrive for Business to a driveletter automatically!
Imagine the following scenario: you get an awesome offer from Microsoft; unlimited, free storage in OneDrive for all your students!
You immediately sign the deal, and scrap all plans to invest in a new fileserver to replace your currently overflowing fileserver containing all student’s data.
Your students work on Continue reading OneDriveMapper released!
Today while implementing a KEMP load balancing solution for ADFS v3 and WAP together with a colleague, I ran into errors on my WAP servers. Both seemed to be connected fine, the IdpInitiatedSignon.aspx page worked….but when I tried to run Get-WebApplicationProxyADFSRelyingParty in Powershell, I got 0x80075227 to chew on.
At first just ADFS+WAP, load balanced, worked, this error surfaced when we added a Non Claims Aware trust to a Sharepoint 2013 Kerberos enabled server so we could publish it using Windows Authentication (which we needed for various BI / Excel components that require Kerberos). The Sharepoint servers were also load balanced, we expect the KEMP has issues with SNI.
Connecting the WAP server directly to ADFS, without the KEMP load balancer in between solved this issue for now, we’re still looking into the configuration of the KEMP with their technicians to find a way to load balance this effectively without compromising on security.
Update: our engineer who worked with KEMP reported that an extra VIP was required because of SNI.
If you hit error 0x80cf401b or 0x80cf0438 when attempting to install the Windows Intune client, disable your proxy or use a network that is not proxied.
In addition, after the Intune Client had been installed, I ran into several other errors that you might also run into. Always check for log files in c:\program files\microsoft\onlinemanagement\logs
The solution to below errors was Continue reading Windows Intune Client on Windows 7 errors 0x80cf401b or 0x80cf0438
You can download the new version here.
- Added checks for .swf and .aspx extensions
- Fixed a bug that causes uploads to folders with illegal names to fail
- Removed dependency on the Start-Transcript function, making it Windows 10 compatible
Due to popular request, I’ve added an analyze function to the O365Uploader. After choosing your folder to be uploaded, a popup will ask you if you wish to see an analysis of potential issues and suggested fixes for your content. Everthing will both be written to the Powershell console in the background and a detailed log file which can be used in MS Excel.
You can download the new version here.
- Added check for period in folder/file name
- Added check for various illegal suffixes in filenames
- Added verification prompt before upload to log all issues to a file beforehand so it can be fixed in advance
- Added warning for 5000+ items
- Added warning for hidden files (start with an _ )
Sometimes, applications require specific host file entries. Often you’d probably be able to get around using DNS to resolve the entries the application really needs. But when you can’t, and you want to virtualise your application using AppV 5, it’ll use the hosts file of the OS instead of the hosts file in the virtualized file system.
To get around this, we can let the AppV client fire off a script to modify the actual OS hosts file upon registration of the AppV application. This is done by modifying the DeploymentConfig.xml file and adding a script to your package, detailed descriptions of how this works can be found here. Basically, you add this between the <Machinescripts> tags in the DeploymentConfig.xml file, example:
The VB code in hostfile_edit.vbs that does the actual work is:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Set fso = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("WScript.Shell")
WinDir = WshShell.ExpandEnvironmentStrings("%WinDir%")
HostsFile = WinDir & "\System32\Drivers\etc\Hosts"
Set filetxtR = fso.OpenTextFile(HostsFile, ForReading, True)
DNSEntry1 = "10.0.0.1 HOSTNAME #DESCRIPTION"
If (checkHostfile(filetxtR, DNSEntry1) = True) Then
Set filetxtA = fso.OpenTextFile(HostsFile, ForAppending, True)
Public Function checkHostfile(filetxt, lineToCheckFor)
checkHostfile = False
Do Until filetxt.AtEndOfStream
s = filetxt.readline
If (s = lineToCheckFor) Then
checkHostfile = True
For anyone in need of a nice and easy to use tool that helps you migrate your folders to Office 365 or OneDrive, check out my Office 365 Uploader.
The tool is totally free, I provide no warranty or dedicated support, use at your own risk.
Because I couldn’t find an answer to this issue anywhere else, and Microsoft Support was unable to determine the root cause I’m sharing this with you. During a cutover migration from Exchange 2003 to Office 365, my batchjob failed after the initial sync and was unable to process incremental syncs of emails in Exchange 2003.
The error in the batchjob’s status display for each failed user was:
ProvisioningFailedException: The name “XXX” is already being used. Please try another name.
Solution: delete the batchjob and all the users it provisioned. Recreate and run it again, and this time, don’t edit the primary SMTP address of these users while the job is running, it is used as a foreign key to match between Onprem and Office 365 and confuses the batchjob if it is changed.
The hint I got that gave me an idea of where this issue was coming from was the following error I received a few times (but not consistently) when changing the primary SMTP address of each user:
You can’t use the domain because it’s not an accepted domain for your organization.
The domain was fully validated and the email was not assigned to any other user.
So, don’t mess around while a batchjob is still running 🙂
Sometimes you want to be able to just double click your powershell scripts and see them work….putting this code at the top of your script will do just that by detecting if the script is running as administrator with administrative priviledges. If not, the script will launch a new instance of itself with an elevation prompt.
$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments