Attempting to share PowerPoint (ppt or pptx) presentations with Skype for Business 2015 fail with: “Some presenting features are unavailable due to server connectivity issues.”

Problem

You’ve noticed that sharing PowerPoint presentations in your Lync 2013 or Skype for Business 2015 business no longer works with the following error message being displayed:

Some presenting features are unavailable due to server connectivity issues.

Logging onto the WAC / Office Web Apps server displays the following errors logged:

Log Name: Application

Source: Application Error

Event ID: 1000

Level: Error

Faulting application name: pptviewerbackendwatchdog.exe, version: 15.0.4502.1000, time stamp: 0x512d2645

Faulting module name: KERNELBASE.dll, version: 6.2.9200.17366, time stamp: 0x554d4531

Exception code: 0xe0434352

Fault offset: 0x000000000004aea8

Faulting process id: 0xeec

Faulting application start time: 0x01d130637d0f659c

Faulting application path: C:\Program Files\Microsoft Office Web Apps\PowerPointViewingServicesWatchdog_App\pptviewerbackendwatchdog.exe

Faulting module path: C:\Windows\system32\KERNELBASE.dll

Report Id: bb35573c-9c56-11e5-9420-005056a10329

Faulting package full name:

Faulting package-relative application ID:

Log Name: Application

Source: Application Error

Event ID: 1026

Level: Error

Application: pptviewerbackendwatchdog.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.TypeInitializationException

Stack:

at Microsoft.Office.Web.Common.ServiceInstanceFinder.GetLocalAgentInstance(Microsoft.Office.Web.Common.OfficeServiceType)

at Microsoft.Office.Web.Common.WatchdogHelper.PrepareRegistrations(Microsoft.Office.Web.Common.OfficeServiceType)

at Microsoft.Office.Web.Common.WatchdogHelper.WatchMachines(Microsoft.Office.Web.Common.OfficeServiceType, CheckServiceInstance, Microsoft.Office.Web.Common.OfficeServiceType, System.String)

at Microsoft.Office.Server.Powerpoint.Watchdog.ViewingBackend.Program.Main(System.String[])

Solution

I wasn’t able to find much material on this issue but the closest match was the following TechNet blog post:

http://blogs.technet.com/b/dodeitte/archive/2013/03/29/issue-with-automatic-updates-enabled-amp-office-web-apps-server-2013-update.aspx

The WAC / Office Web Apps server in this environment wasn’t on automatic updates but the administrators simply install any updates that are available on a routine schedule.  The KB2760445 wasn’t on the list of updates installed onto the server but as I didn’t have any other leads, I went ahead to uninstall Office Web Apps, then the language pack, then reinstalled all the components in the following order;

1. Office Web Apps Server 2013
2. Office Web Apps Server Language Pack 2013
3. Office Web Apps Server 2013 SP1

Once reinstalled, I recreated the Office Web Apps Server Farm and noticed that everything was working again.

A few notes worth mentioning that I noticed:

1. There is no need to install https://support.microsoft.com/en-us/kb/2760445 as noted in the TechNet blog above as the Office Web Apps Server 2013 SP1 covers it
2. I tried installing Office Web Apps Server 2013 SP1 prior to uninstalling and that did not fix the problem

Just for reference, the following version is Office Web Apps Server 2013 pre-SP1:

15.0.4420.1017

The following version is Office Web Apps Server 2013 after installing SP1:

15.0.4571.1502

NetScaler load balanced StoreFront server throws the error: “Cannot complete your request.”

I’ve noticed that I’ve been asked about the following error quite frequently over the past year so I thought writing a blog post may help anyone who might be searching for an answer to this problem.

Problem

You’ve configured a Load Balancing Virtual Server on your NetScaler appliance which you use to direct NetScaler Gateway Virtual Server requests to your StoreFront servers:

Accessing the StoreFront portal and authenticating through the NetScaler works fine but you notice the following error if you try to access the URL of the Load Balancing Virtual Server internally to bypass the NetScaler Gateway authentication page:

Cannot complete your request.

Clicking the OK button will cycle through the previous prompts and end with the same message.

Solution

While there are many reasons why this error would be thrown as outlined in the following KB:

http://support.citrix.com/article/CTX133904 http://docs.citrix.com/en-us/storefront/3/integrate-with-netscaler-and-netscaler-gateway/load-balancing-with-netscaler.html?_ga=1.149961662.983477202.1446337615

Two of the most frequent reasons I’ve seen is either the need to create a host record on your StoreFront servers to resolve the FQDN URL you are using to send traffic to your NetScaler’s Load Balancing Virtual Server to resolve to itself or that Integrated Caching is enabled on the NetScaler:

Try turning this feature off if you are experiencing this issue:

Unable to reinstall VMware Tools onto virtual desktop

I recently ran into an interesting issue where I went through a series of troubleshooting steps that eventually led me to reinstalling the VMware Horizon View Agent on a master image but quickly realized I wasn’t able to.  The error messages I was presented wasn’t too helpful so I thought writing this blog post may help others who may encounter the same problem.

The whole process started off with an administrator asking me to look at why a user wasn’t able to connect to their virtual desktops after we recompose their VDI with the latest snapshot that recently had 2GB of Windows updates installed.  The user would attempt to log onto the View environment as such:

The Connection Server is preparing the desktop…

They would see a black screen as such:

Then they would get cut off and displayed the following error message:

VMware Horizon Client

The connection to the remote computer ended.

Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDM\logs folder:

\\VDI-001\c$\ProgramData\VMware\VDM\logs

… then opened one of the pcoip_agent logs to review the entries.  Some of the entries I noticed were:

Server died.

… and:

disconnect reason: 0

The follow log entries are as follows:

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0

11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6

11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C

Reviewing the View Connection server’s logs from the folder:

C:\ProgramData\VMware\VDM\logs

… reveal the entry:

2015-11-17T14:17:10.024-04:00 DEBUG (0C70-094C) <e1f29aa5-68ed-437b-ad9f-cc1759d63d8b> [DesktopTracker] onEvent: PENDING_EXPIRED - UserName:a-tluk;DomainName:CONTOSO;UserDn:cn=s-1-5-21-206374890-975330658-925700815-10626,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int;UserSid:null;GroupSids:null;BrokerUserSid:S-1-5-21-206374890-975330658-925700815-10626;ConnectionId:fcca_***_1220;Protocol:null;ClientName:null;ClientAddress:null;ServerDn:cn=a34734d6-4e78-4d07-83c4-5ce3d1ce31cd,ou=servers,dc=vdi,dc=vmware,dc=int;ServerPoolDn:cn=standard_CON_desktop,ou=server groups,dc=vdi,dc=vmware,dc=int;ServerDnsName:CONFSTAWKST-158.tokiomillennium.com;DynamicIpAddress:10.23.0.92;ManagedObjectId:null;Id:e1f29aa5-68ed-437b-ad9f-cc1759d63d8b;State:PENDING_EXPIRED;SessionGuid:c80b-***-2d5b;PreviousSessionGuid:null;LoggedInAsDomain:CONTOSO;LoggedInAsUser:a-tluk;SessionType:DESKTOP;RemotableContent:null

Reviewing the Events database in the View Administrator console reveals the following:

The pending session on machine <VDIname> for user contoso\a-tluk has expired.

What I’ve done in the past for troubleshooting black screen disconnection issues was to reinstall the VMware Horizon View agent but what I noticed was that attempting to install the View Agent on the master image after uninstalling it would briefly show the splash screen, disappear and nothing would happen.  From there, I proceeded to uninstall VMware Tools and reinstall it but quickly noticed that the install would fail with the message:

VMware Product Installation

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.

Attempting to copy the installer onto the desktop and run the install would generate the following error message:

Setup failed to extract the files necessary to install VMware Tools.

From here on, what ended up being the cause of all these issues was actually because there was no space in the %temp% directory to extract the installation files. The reason why this was the case was because the environment I was working in had SanDisk’s ioVDI solution deployed and the %temp% folder was redirected to a disposable disk that also stored the page file which had already filled up the disk.  This was why the installer for VMware Tools and the Horizon View Agent would fail and it was also why the user had connection issues.

The whole ordeal concluded in a way that I did not expect so I hope the error messages I outlined here would be able to help anyone who happens to come across a similar issue with the same cause.

Reconfiguring a domain previously federated via ADFS with another Azure directory

I recently had to remove the federation between an on-prem Active Directory and an Azure Directory so that we could re-federate the on-prem Active Directory to a new Azure Directory.  The process is quite easy but there doesn’t appear to be clear documentation for the steps so I thought it would be worth while writing this blog post just in case I ever had to do this again in the future.

Begin by removing the domain from the Azure Directory that you no longer need it to be federated to.  The tasks required are as follows:

• Stop the DirSync
• Disable ADFS federation
• Delete the directory (you can’t have the same on-prem directory added to more than one Azure Directory)

Within the new Azure Directory that you are going to federate the on-prem directory to:

• Create a new global admin account for this Azure Directory
• Add the new domain to Azure Directory
• Create the required TXT record to verify the domain
• Launch the WAAD console and execute Connect-MsolService
• Log in with the global admin account for the Azure Directory
• Execute Get-MsolDomain to ensure that the on-prem domain is listed and the Authentication field is listed as Managed

• Execute Set-MsolADFSContext -computer <yourInternalADFSserverFQDN>
• Execute Convert-MsolDomainToFederated -DomainName <domainToFederateFQDN>

• The federation to the previous Azure Directory would have created a Microsoft Office 365 Identity Platform in the Relying Party Trusts folder in the AD FS console as shown here:

• Proceed by deleting it:

• Then recreating it by executing Update-MsolFederatedDomain -domainname <domainToFederateFQDN>

• Refreshing the Relying Party Trusts folder should now show a recreated Microsoft Office 365 Identity Platform
• Reconfigure and then run DirSync now to synchronize the on-prem Active Directory with the Azure Directory

Unable to delete newly created Active Directory in Azure

Problem

You’ve recently created a new Directory in Azure but noticed that you created it in the wrong Location and since it is a new directory with no objects created, you decide to delete quickly notice that you are unable to with the following message presented:

Delete directory

Cannot delete ‘<Directory Name>’

The following issue(s) prevent deletion of this directory:

Directory contains one or more applications that were added by a user or administrator.

Solution

The reason why a seemingly new directory cannot be deleted is because the creation process automatnically creates applications that needs to be manually deleted.  The following KB outlines the process:

You can’t delete a directory through the Azure Management Portal
https://support.microsoft.com/en-us/kb/2967860

The suggested cmdlet that the KB above suggest to be executed is:

Get-MsolServicePrincipal | Remove-MsolServicePrincipal

What I’ve noticed from most colleagues or clients who ask me about this is that they are unsure as to how to run this safely without accidentally deleting applications associated with directories and objects that are in their Azure account.

With this in mind, the correct method of deleting applications associated with the directory you want to delete is to log in with the global administrator of your subscription account that you used to create this directory and create a new global admin for this directory itself:

Ensure that Global Admin is selected:

Continue to create the temporary password:

As this is a new account with a temporary password, you will need to log into the https://login.microsoftonline.com portal once to configure a password first otherwise you won’t be able to log in via remote PowerShell:

Once the password has been set, proceed to launch the Windows Azure Active Directory Module for Windows PowerShell and execute the Connect-MsolService cmdlet, authenticate and execute Get-MsolServicePrincipal:

The list of applications display should only be specific to the directory you are attempting to delete as you are logged into the account that was just created.  Proceed to execute the cmdlet Get-MsolServicePrincipal | Remove-MsolServicePrincipal to delete the applications:

Note that there will be some applications that can’t be deleted as shown in red so it is safe to ignore them.

With the applications deleted, continue by logging in as the global administrator subscription account used to create the directory, delete account that was created and finally delete the directory:

Delete directory

Select the checkbox to delete ‘<Directory Name>’. This can take an hour or more.

Deleting ‘<Directory Name>’ cannot be reversed, and will delete all resources in the directory.

Hope this clarifies the process of safely removing an Azure hosted directory.

Accessing the Update Password webpage published by an ADFS server displays the error: “An error occurred. Contact your administrator for more information.”

Problem

You’ve successfully deployed ADFS in your on-prem environment and would like to use the password change portal that the server provides but you notice that navigating to https://adfs.domain.com/adfs/portal/updatepassword displays the following error:

Expanding the Error details displays the following:

Error details

· Activity ID: 00000000-0000-0000-1400-0080000000d3

· Error time: Wed, 16 Sep 2015 14:02:27 GMT

· Cookie: enabled

· User agent string: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; InfoPath.2; MS-RTC LM 8; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MS-RTC EA 2; .NET4.0C; .NET4.0E)

Solution

The reason why the portal is not functioning properly is because you are attempting to use a workstation that isn’t joined to the domain to access this page.  The initial design of this service requires authenticated or registered devices that are joined to the domain but Microsoft changed the relaxed the requirement after receiving feedback from customers.  The patch that relaxes this constraint can be found in the following KB:

https://support.microsoft.com/en-us/kb/3035025#/en-us/kb/3035025

The webpage should function as expected once the patch is applied:

More information about the setup and why the requirement was relaxed can be found in the following MSDN blog post:

Note: ADFS 2012 R2 required authenticated/registered devices (a.k.a ‘workplace join’) to allow the change of passwords. Based on customer feedback, we have relaxed this constraint and allow this from all devices. You will need to apply 3035025 hotfix on all the ADFS servers.

http://blogs.msdn.com/b/samueld/archive/2015/05/13/adfs-2012-r2-now-supports-password-change-not-reset-across-all-devices.aspx

Citrix XenDesktop 7.6 published through a NetScaler throws the error: "This webpage has a redirect loop" error after upgrading from NS11.0 55.20.nc to NS11.0 63.16.nc

Problem

You have a working Citrix XenDesktop 7.6 with StoreFront 3.0 published through a NetScaler VPX appliance NS11.0 55.20.nc that has been stable for quite some time and have decided to upgrade the NetScaler to the latest NS11.0 63.16.nc.  You proceed to go through the upgrade of the appliance:

The appliance appears to be operational as navigating to the portal URL displays the authentication page presented by the NetScaler:

However, you notice that you are not able to successfully log into the portal after entering the credentials because the Internet Explorer browser simply presents a white screen:

You attempt to use Chrome to test instead:

Then notice that instead of a white page, the browser terminates the attempt and displays the message:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Expanding the Details option displays the following:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Reload

Hide details

The webpage at https://access.domain.com/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Learn more about this problem.

Solution

While there may be various causes as to why this error would be thrown, the cause for the environment I worked in was because the upgraded NetScaler did not appear to like the redirect configuration I had in IIS on the StoreFront server:

The Web Interface Address in the NetScaler Gateway Session Profile was configured without the full directory path:

https://storefront.domain.com

What ended correcting the issue was to remove the redirect configured on the IIS properties of the StoreFront server:

… and using the full URL path for the StoreFront website:

https://storefrontdr.domain.com/Citrix/UKWeb

Note that I’ve also tried upgrading the StoreFront server to 3.0.1.55 but that did not correct the issue: