O365Uploader V0.4

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.

Other changes:

  • 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 _ )

Changing or virtualizing the Hosts file with AppV 5

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:

<AddPackage>;
 <Path>c:\windows\system32\wscript.exe</Path>
 <Arguments>{AppVPackageRoot}]\Scripts\hostfile_edit.vbs</Arguments>
 <Wait RollbackOnError="true" Timeout="10"/>
 </AddPackage>

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
 WScript.Quit(0)
 Else
 Set filetxtA = fso.OpenTextFile(HostsFile, ForAppending, True)
 filetxtA.WriteLine (DNSEntry1)
 filetxtA.Close
 End If
filetxtR.Close
 WScript.Quit(0)
Public Function checkHostfile(filetxt, lineToCheckFor)
 checkHostfile = False
 Do Until filetxt.AtEndOfStream
 s = filetxt.readline
 If (s = lineToCheckFor) Then
 checkHostfile = True
 Exit Function
 End If
 Loop
 filetxt.Close
 End Function

Office 365: ProvisioningFailedException: The name “XXX” is already being used. Please try another name.

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 🙂