Xbox One Headset Adapter – Sharkoon Xtatic Pro Headset Fix

Note: This has nothing to do with SharePoint or Solutions Architecture. :)

The problem with the new Xbox One Headset Adapter is that it simply does not work with a standard TRRS 4-pole (3 ring) 3.5mm male to male cable or standard 3.5mm stereo auxiliary cable.

Working example:

4-pole TRRS Does not work - Xbox audio feeds back into the microphone:
 

Does not work (at all) or with stereo 3.5mm:

FIX:

Using the Xbox 360 cable (with modifications) that came with the Sharkoon Xtatic Pro and the new 2.5mm adapter together, we get a working cable.

Unscrew the 2 screws using the small Phillips head screwdriver.

Lift up on the plastic wings and then pull back.
 

I had already clipped the tabs off in the above pictures but you don’t need to do this.  Instead you just cut off the entire wing as pictured here.
 

Post surgery:

Now just wrap it with a small piece of electrical tape.

Now plug it into the 2.5mm adapter that came with the Xbox One headset adapter and all should work.  However you may want to turn down the adapter game volume so you only get voice through the adapter and not game audio, since you get that through the optical surround sound adapter.  Also note that this is mono, not stereo so you could alternatively modify a TRRS 4-pole cable to provide that stereo headset sound you’ll never use.

SharePoint Farm Infrastructure Architecture Recommendations

Following are some recommendations for a typical SharePoint Development environment topology:

In addition to the corporate Test/Stage and Prod farms, I recommend a standalone Dev VM for each of your MSDN subscriptions/developers.  Development VMs contain a standalone single server farm as well as all development tools.  Any content only solutions (OOB site collection or web scoped) should be configured directly in Production in a new site collection.  Custom development (Visual Studio) is completed on the development VMs, released to Stage, tested, and then released to Prod.  Each Dev VM should be semi-isolated from the corporate network (separate subnet and domain).  Dev VMs should be disposable, distributable, and standardized as in my article here: SharePoint 2010 Development Farm VM

In this way every new developer would only need to copy the VM to their workstation and would be up and running after connecting to Source Control.  They would also have full control of their VM so IT admin requests would be minimized.  Simply recopying the template VM would fix any issues.

The development VM operating system drive should be a solid-state drive.  Optionally, an external BLOB storage and search index partition may be stored on a low cost drive (requires a little more configuration).  Workstations must support hardware virtualization.

The Test/Stage servers may need to be used for debugging and development of integration issues.  Alternatively, a standalone Dev farm on the corporate network can be set aside for this purpose.

In each case, a process for synchronizing Production site collections back onto the Test/Stage and Dev VMs should be maintained.  Usually this includes site collection backups being made available as needed.  However care must be taken to ensure information security policies are maintained.  This can include scrubbing/redacting content, disabling alerts and emails (this may be done through network isolation), and populating sample data.