Exporting XenDesktop / XenApp 7.6 Policies

If you’re looking for a way to export your policies in XenDesktop / XenApp 7.6, these two methods export XML files for archival or reporting.

Method 1

Download XenApp Migration Script:


Extract the readIMA folder

Do not load any modules before performing this operation.

PS C:\readima> Import-Module .\ExportPolicy.psd1

PS C:\readima> Export-Policy -XmlOutputFile .\MyPolicy.XML -LogFile .\MyPolicy.log

PS C:\readIMA> Export-Policy -XmlOutputFile .\MyPolicy.XML -LogFile .\MyPolicy.log

XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version 20141125-1515

Exporting user policies

Exporting policy “Unfiltered”

Exporting policy “Disconnected Session Timer”

Exporting policy “HTML5”

Exporting policy “Printing”

4 user policies exported

Exporting computer policies

Exporting policy “Unfiltered”

Exporting policy “HTML5”

2 computer policies exported

Policy export completed

Log has been saved to .\MyPolicy.log

PS C:\readIMA>

*NOTE* This creates one policy file with filters included

Method 2

Download Scout


From the Scout\Current\Utilities folder, copy Citrix.GroupPolicy.Commands.psm1 to C:\

PS C:\> Mkdir C:\MyPolicy

PS C:\> Add-PSSnapin Citrix.Common.GroupPolicy

PS C:\> Import-Module .\Citrix.GroupPolicy.Commands.psm1

PS C:\> New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhost

PS C:\> Export-CtxGroupPolicy –Drive Site C:\MyPolicy

*NOTE* Using this method exports three files, one contains policy settings, a separate contains filters

System UIDs Inconsistent – Android

Recently in my tinkering of system APKs, I encountered an error upon reboot: System UIDs Inconsistent.

I thought this could be from me re-adding the Gallery apk since that was the last action before the error, but it turns out it was much more.At some point, I got corruption in my data partition.  I still don’t know how this happened, but a couple identifiers let me know the culprit.

First, I reboot into recovery (TWRP) and ran a permissions fix.  Part of the output told me that it could not access /data/data/com.RiteshSahu.SMSBackupRestore.  I used this app to backup my SMS messages when changing ROMs, so I figured I would simply remove it and the data folder to get rid of the offending problem.  This was not that easy.  In Root File Explorer, there was no folder “data/data/com.RiteshSahu.SMSBackupRestore”.  Hmmm.

Rebooting back into Recovery, I ran permissions fix again to see if the directory was now cleaned out, but received the same error.  I successfully ran a data backup in order to preserve any settings I may lose, so I figured next would be deleting data and then restoring it.  The problem followed.  I even tried to reinstall the app (which I noticed the APK was gone and no longer showed as an installed app).  When trying to reinstall, I received “Unknown Error code during application install: -24” and the install failed.  Next step: Drop to terminal and see if I can remove the folder.

In TWRP, you can easily open a terminal in any folder, so I dropped into /data/data and ran “ls”.  Sure enough – there’s the folder.  Let’s delete it with “rm com.RiteshSahu.SMSBackupRestore”.  A quick “ls” showed me the folder was now gone. Reboot and voila! – No more UID error.

I know this would have been a major pain without the permissions error pointing me in the right direction.  Lesson learned to use multiple approaches to identify the problem.  Good luck to any others who stumble across this error.

Bugcheck 9f Dell e6410

Recently had ANOTHER BSOD during sleep on my Dell e6410.  Let’s see what caused it:

*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Use !analyze -v to get detailed debugging information.
BugCheck 9F, {3, fffffa800748b060, fffff80000b9c518, fffffa80071d6b80}
Probably caused by : pci.sys
Followup: MachineOwner

0: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

A driver is causing an inconsistent power state.
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800748b060, Physical Device Object of the stack
Arg3: fffff80000b9c518, Functional Device Object of the stack
Arg4: fffffa80071d6b80, The blocked IRP

Debugging Details:
IMAGE_NAME:  pci.sys
FAULTING_MODULE: fffff88000f59000 pci

fffff800`00b9c4c8 fffff800`02eef8d2 : 00000000`0000009f 00000000`00000003 fffffa80`0748b060 fffff800`00b9c518 : nt!KeBugCheckEx
fffff800`00b9c4d0 fffff800`02e8a85c : fffff800`00b9c600 fffff800`00b9c600 00000000`00000000 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x33af0
fffff800`00b9c570 fffff800`02e8a6f6 : fffff800`0302ff80 00000000`00d54724 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff800`00b9c5e0 fffff800`02e8a5de : 000001fb`af0e19ca fffff800`00b9cc58 00000000`00d54724 fffff800`02ffd708 : nt!KiProcessExpiredTimerList+0xc6
fffff800`00b9cc30 fffff800`02e8a3c7 : 0000007d`4901dfc1 0000007d`00d54724 0000007d`4901dfdc 00000000`00000024 : nt!KiTimerExpiration+0x1be
fffff800`00b9ccd0 fffff800`02e778ca : fffff800`02ffae80 fffff800`03008cc0 00000000`00000002 fffff880`00000000 : nt!KiRetireDpcList+0x277
fffff800`00b9cd80 00000000`00000000 : fffff800`00b9d000 fffff800`00b97000 fffff800`00b9cd40 00000000`00000000 : nt!KiIdleLoop+0x5a

FOLLOWUP_NAME:  MachineOwner
FAILURE_BUCKET_ID:  X64_0x9F_3_NETwsw00_IMAGE_pci.sys
BUCKET_ID:  X64_0x9F_3_NETwsw00_IMAGE_pci.sys
Followup: MachineOwner

0: kd> !irp fffffa80071d6b80
Irp is active with 5 stacks 3 is current (= 0xfffffa80071d6ce0)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    
            Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    
            Args: 00000000 00000000 00000000 00000000
>[ 16, 2]   0  0 fffffa800a4a0050 00000000 00000000-00000000    
          Unable to load image \SystemRoot\system32\DRIVERS\NETwsw00.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for NETwsw00.sys
*** ERROR: Module load completed but symbols could not be loaded for NETwsw00.sys
            Args: 00014400 00000001 00000004 00000002
 [ 16, 2]   0 e1 fffffa8009d43ac0 00000000 fffff80002e6b710-fffffa800b3c1520 Success Error Cancel pending
           \Driver\vwifibus    nt!IopUnloadSafeCompletion
            Args: 00014400 00000001 00000004 00000002
 [  0, 0]   0  0 00000000 00000000 00000000-fffffa800940daa0    
            Args: 00000000 00000000 00000000 00000000

0: kd> lm vm NETwsw00
start             end                 module name
fffff880`068a7000 fffff880`073f9000   NETwsw00 T (no symbols)           
    Loaded symbol image file: NETwsw00.sys
    Image path: \SystemRoot\system32\DRIVERS\NETwsw00.sys
    Image name: NETwsw00.sys
    Timestamp:        Wed May 29 09:10:47 2013 (51A5FE57)
    CheckSum:         00B0B5C3
    ImageSize:        00B52000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Looking at what this module is on my filesystem, I can see that this is an Intel Wifi Link Driver. Hmmm. I just updated my drivers recently to fix the same problem. I guess Intel did not fix the BSOD issue.  Checked for an updated driver, and voila!  Let’s hope this one fixes the problem.

MultiWii Mixing for TBS Discovery

Firstly, I don’t have a TBS Discovery – I’m cheap.  But, I did use the pattern of the Discovery to make my quad out of 1/8″ plywood.  It seems like a popular layout that doesn’t allow props in the video, so I went with it.  Now I just need a mix to accommodate the oddball motor layout.  Here’s how.

Firstly, I owe all the credit to Adam Polak  here: http://polakiumengineering.org/?p=1612

This procedure is for my Witespy Mega Ez 3 board.  It is a Mega 2560, so some info to note is:

Motor 0 = Digital Pin 3
Motor 1 = Digital Pin 5
Motor 2 = Digital Pin 6
Motor 3 = Digital Pin 2
Motor 4 = Digital Pin 7
Motor 5 = Digital Pin 8
Motor 6 = Digital Pin 9
Motor 7 = Digital Pin 10

Motor layout with relation to Pin is shown here:


I took a picture of my quad and overlayed a grid on the picture.  This made it easy to get some numbers for ratios.


Adam Polak says on his web page:

Using the grid as an aid, determine the magnitude of the pitch, roll and yaw mix by measuring the coordinates of the motor. For example, the mix for this quadx would be:

#if def QUADX
motor[0] = PIDMIX(-1,+1,-1); //REAR_R
motor[1] = PIDMIX(-1,-1,+1); //FRONT_R
motor[2] = PIDMIX(+1,+1,+1); //REAR_L
motor[3] = PIDMIX(+1,-1,-1); //FRONT_L

The syntax of the mix would be as follows:

*Be aware of the sign change!

“motor[‘motor number’] = PIDMIX( ‘- X-Coordinate’, ‘- Y-Coordinate’, ‘Rotation (‘clockwise ‘-’, counter-clockwise’+’)’);

Looking at my grid, I can modify the standard QuadX configuration to be:

motor[0] = PIDMIX(-1,+3/4,-1); //REAR_R
motor[1] = PIDMIX(-5/4,-3/4,+1); //FRONT_R
motor[2] = PIDMIX(+1,+3/4,+1); //REAR_L
motor[3] = PIDMIX(+5/4,-3/4,-1); //FRONT_L

Armed with that information, I need to make 4 changes to the MultiWii sketch

  1. In Output.ino, add the following config for QUADXDISCO:
    #ifdef QUADX
     motor[0] = PIDMIX(-1,+1,-1); //REAR_R
     motor[1] = PIDMIX(-1,-1,+1); //FRONT_R
     motor[2] = PIDMIX(+1,+1,+1); //REAR_L
     motor[3] = PIDMIX(+1,-1,-1); //FRONT_L
     #ifdef QUADXDISCO
      motor[0] = PIDMIX(-1,+3/4,-1); //REAR_R
      motor[1] = PIDMIX(-5/4,-3/4,+1); //FRONT_R
      motor[2] = PIDMIX(+1,+3/4,+1); //REAR_L
      motor[3] = PIDMIX(+5/4,-3/4,-1); //FRONT_L
     #ifdef Y4
     motor[0] = PIDMIX(+0,+1,-1);   //REAR_1 CW
     motor[1] = PIDMIX(-1,-1, 0); //FRONT_R CCW
     motor[2] = PIDMIX(+0,+1,+1);   //REAR_2 CCW
     motor[3] = PIDMIX(+1,-1, 0); //FRONT_L CW

    This is line 843 in MultiWii 2.2

  2. Add the frame definition to Config.h:
    //#define QUADP
     //#define QUADX
     #define QUADXDISCO
     //#define Y4
     //#define Y6
  3. In def.h in the section labelled “Multitype decleration for the GUI’s”, I changed this line:
    #elif defined(QUADX)
     #define MULTITYPE 3


    #elif defined(QUADX) || defined (QUADXDISCO)
     #define MULTITYPE 3

    This allows the GUI to display the correct craft type.

  4. Also in def.h, find the following line (line 135 in MultiWii 2.2):
    #elif defined(QUADP) || defined(QUADX) || defined(Y4)|| defined(VTAIL4)
     #define NUMBER_MOTOR     4

    Add another condition for your model:

    #elif defined(QUADP) || defined(QUADX) || defined(Y4)|| defined(VTAIL4) || defined(QUADXDISCO) 
     #define NUMBER_MOTOR     4


Once these changes were made, I opened up MultiWii WinGUI to save my settings to file (don’t wanna recreate the wheel), then loaded the EEPROM_CLEAR sketch to ensure a clean upload.  Once cleared, I loaded up the new MultiWii sketch, uploaded my settings via WinGUI and went for a test flight.  So far so good, but unfortunately it started raining right when I got in the air, so more updates to come.

Flashing F-30a ESCs with SimonK

Flashing F-30A or F-20A ESCs is easy with a USBasp adapter.

You’ll need the following:

Reference This Spreadsheet and find your ESC.  In this case, I am flashing F-30A ESCs, so I will use firmware file “bs_nfet.hex”.

Using the following images, I can match up the 6 or 10 pin connector to the necessary points on the ESC.

6Pin ISP ISP 10-pin connection-pinout

This image shows the corresponding points on the ESC.  Rather than removing the entire case, use the razor blade to cut open a window to the solder points we need our wires to contact.


I used two servo extension wires with the male leads pressed into the 6 pin connector of the USBasp programmer.  On the other end, I stripped the wires back a little bit and dabbed a little solder on them to keep them stiff.  I can then hold them in place with my fingers while the programmer does its job.


Open the kkMulticopter Flash Tool and note the settings in the screenshot.


I can choose the file directly by using the disk icon and then flash that file with the arrow next to it, or I can allow the tool to download the firmware file automatically by selecting the firmware shown and then use the arrow next to the firmware section.

My firewall blocked this app, so I manually downloaded the file and flashed it using the file option.  If you want to allow the tool to download the firmware, you can skip downloading from the firmware link above.

Be sure to hold the wires steady and firm onto the ESC during flash.  If it fails the first time, adjust your grip and try again.  I flashed 4 ESCs in about 5 minutes with a couple failures while getting the wires to touch all pads firmly.

Good luck!

FS-TH9x mods

Now that I’m knees deep in this hobby, I need a better transmitter that supports multiple models.  The FlySky TH9x (Same as the Turnigy 9x) is a 9 channel transmitter which has a ton of options for upgrade.  This is a very versatile transmitter when it comes to modification, firmware, and upgradeable parts.  For a $79 price tag, it’s a deal compared to higher priced models.

Changing firmware is my first upgrade.  The popular ER9x code is available from HERE which fully supports any of the FS-TH9x flavors.  Flashing the 9x can be somewhat daunting and usually requires some soldering, engineering a connector into the case somewhere, and programmer such as a USBASP.  I chose the route of the SmartieParts 9x Solderless Programmer Board.  This is a drop-in board that adds a small USB port inside the battery compartment.  All you have to do is open the case, install the board with a few screws, mount the usb port, and you’re done!

While the case is open, you may as well order a back-light for your screen.  This is a great $5 upgrade you can find HERE.  The smartieparts board above even has a port to power this back-light.  It only requires cutting the existing lead that comes with the back-light and soldering the two-wire plug that comes with the programmer board to the existing wires.  After that, it drops in as easy as the programmer board.

Flashing ER9x was a breeze with the exception of one hang-up.  Use the driver and flashing software for the programmer board that SmartieParts provides on their website.  I did not get regular windows drivers to work.  After that, it’s smooth sailing into a powerful firmware.

My next upgrade is a FrSky DJT transmitter module with Telemetry receiver.  Smartieparts also sells a board to easily integrate FrSky telemetry into the 9x display.  I opted for the FrSky add-on display mostly because I forgot about the SmartieParts adapter.  D’oH!  Those parts should arrive in a couple weeks, so I will update this entry at that time.

The Tricopter Saga

After building the first tricopter, I found some things about it that I didn’t like.  The body was small and doesn’t allow for much electronics.  Because of that, the flight controller, camera gimbal, receiver, and battery are all hanging off of it somehow or stuck to it with double sided tape.  I wanted something that would have a place for everything and protect it if possible.

I came across the Simple T-Copter design from simplecopter.com which has the flight controller and receiver recessed int he body.  Great idea.  What I wasn’t so much on was the “T” design.  It seems like the center of gravity would be off.  As a compromise, I made a hybrid of the tricopter v2.5 and the T-Copter.  Ideally, two bearings would inset in the platform with a matched shaft drilled into the boom, but – we’ll see if those parts turn up.

This design was pretty nice.  The platform on the front allowed me to add a camera gimbal (I used the “super simple gimbal”).  The copter flew well, but when I finally got a GoPro, the propellers were in view.  *sigh.  This called for something with the camera further forward to get the propellers out of frame.

Version three was based off of the T-Copter design.  One thing the designer claimed is that the props are out of view when the camera sits on the front.  This is true. Video looks good with no propellers in frame.  Design note: keep the GoPro directly between the propeller center.  I failed to take many pictures of version three which is unfortunate because I was proud of how I integrated the gimbal (SSG) into it.  I kept the camera mount on top, but the servos were on the bottom with an extended  fuel line going through the body.  I had to add some wire inside the fuel line to keep it rigid through the body, but it worked!

The T-copter design was great.  As long as you mount the battery to the rear, the center of gravity isn’t too bad.  It was not as stable on high throttle as the original tricopter.  I also experienced some jitters with the gimbal that I think were due to the extended fuel line tubing used to attach the platform to the servos catching on the holes in the body.  I want to build another, but the next one will keep some arm angle, have the gimbal detached from the main platform, have all electronics inline with the FC and receiver recessed, and have a designated place to strap the battery.

My next model will not have the steering mount yaw mechanism.  While this seems like a good idea from RCExplorer, I find that if my motor has any vibration, it can resonate due to the “looseness” of the extended joint.  I think the method of using a bolt or screw through a wooden platform, then attaching a servo to the platform, is going to prove a more stable mounting solution.  This was the first mounting method by RCExplorer and the method still used on the T-Copter.

The body is two similar pieces with the lower piece having an extended platform on the tail to mount the battery.  I guess it could be smaller, but the surface area touching the battery makes me think it’s more snug.  I used 1/2″ spacers/risers to separate the two body plates and attached them with  4×1/2″ screws.  Two openings in the top piece allow for access to the KK2 board and the receiver.  Simple triangular pieces attached to the arms allow for a decent looking landing gear.  The motors are no longer DT750’s.  Instead, I upgraded to SunnySky 2216-12 800kv motors.

What I’ve learned after the fourth copter:

  • The gimbal jitter was not from having extended tubing.  It’s the darn servos! Apparently this is a widespread problem and finding servos that don’t bounce around is difficult.  I tried a torroid ring on my signal line which made no difference.  For now, unhooking the servos gives me great ideo, but I have to deal with the flight movement.
  • You get what you pay for. While the DT750 motor is great and efficient, it takes forever to get balanced properly.  The SunnySky motors bolted on and with about 5 minutes total of dynamic balancing, DONE.  Smooth out of the box.
  • Be careful not to set your “P” too high on Yaw.  If it starts going back and forth, it gets nasty!
  • Don’t integrate a gimbal into the body.  Make it attachable by some means.  On Gen. 4, I used four fuel line pieces on screws to add some more vibration isolation, but the main point of keeping it separate is so you can make changes without modifying your body.