SSRS with Dynamics 365 / CRM and multi value parameters not setting their defaults correctly

Scenario:

(Search keywords:  SSRS multi-value-parameter hard-coded values default value FetchXML CRM)

I've created a multi value parameter and manually entered lots of labels/values.

I've gone to the default tab and picked on one of the values.

Copied the changed report up to the CRM using the XRMToolbox ReportSync tool.

Run the report - the default(s) aren't as wished (or in my case didn't seem to have worked at all) so I changed them, re-pushed, and they still don't work.

Issue:  A little exploratory testing seemed to indicate that the CRM isn't paying any attention to changes in the default value(s) when I push the new version of the report up.  (Note that I'm not doing a publish all because there are other users on the system - not sure if that would have made a difference.)

Solution:  Or one, and easy in my case because I'm trying to get the parameter defaults sorted before I've actually used it anywhere:  Change the parameter name and re-push.  (Then change it back again if you want.)  

[There might be other solutions like changing some of the values - not sure.]

Gen2 2007 Prius Front Right ABS Sensor

So I've bought what I hope is an aftermarket Gen2 2007 Prius Front Right ABS Sensor (wheel speed) off Ebay.

I reckon the correct Toyota part number for this (right-hand-drive) car is 8954247020 or 89542-47020.
This part is made by Herth+Buss and according to the web has part number J5912045 or EAN 4029416234959, but the only number I can see printed on it is on the lead where it says
Herth+Buss 2973600-1019 - a number unknown to Google!

I just stuck a multimeter across the plug's contacts and that gave me an ohm resistance reading of 1.57 ohms.    (I saw a youtube video where the bloke was replacing one - might have been on the Gen3 - and his new one had a resistance similar to mine;  the one he took off measured 2-point-something, I think.)

I'll be getting the garage to fit this soon (when they replace a caliper that appears to be binding and causing some unnecessary heat and some very unnecessary intermittent wheel-squeaking) so I don't know if this is going to fix the problem yet.  (That goes for the caliper too :-(  )
However, the garage told me the wheel teeth are okay, and this part cost me about £40 instead of the genuine Toyota part's £200+, so I figure it's worth a shot.


UPDATE:  Replacement part now fitted and I got the garage to give me the old sensor back.  It registers 1.64 ohms and varies (just a little bit, somewhere less than 0.1 ohms?) when I flash my keys or something else metal across it.   
That doesn't inspire much hope that we've fixed the problem therefore, but what might give me a little bit of hope is that the end of the little metal pin on the sensor does appear to have a little gouge / scratch across it - like it's come into contact with something on its travels.
I'll have to wait till I've taken the car on the motorway to see if it's worked.
(The garage reported that the old caliper was definitely binding, but that pads and disc are still currently okay - so good news on that front.)

FURTHER UPDATE:  I had two problems with the old sensor: the car would shudder coming to a low-speed stop as the ABS decided it needed to kick in and out a bit, even with a gentle slow down (come to think of it, the ABS has always been a little eager to kick in when stopping since I first got the car);  the ABS warning lights would come and and stay on when I got to (let's say around) 70 mph.)   The new sensor has definitely fixed the low speed stopping issue;  however, when I get to (let's say a fast) 70mph the ABS light has still come on.  (It almost always automatically resets after a restart or two, whereas it used to hand around longer than that before.)   My conclusion:  Yep, the old sensor was a bit dodgy, but I suspect there's a small bit of damage to the toothed wheel too - probably should have got the garage to replace that at the same time, regardless of the garage's assurances.  [Mind you - I haven't checked the price of one!]

Rank / Execution Order of synchronous / real-time workflows in Dynamics 365

There's a "rank" field in the sdkmessageprocessingstep entity.  (You can see the entity through Advanced Find but you don't seem to be able to access that field, which has a display name of Execution Order.)


I'm using online Dynamics 365 / CRM / Customer Engagement,
Version 1710 (9.1.0.5424) online

XrmToolBox has an "Synchronous events execution order" plug-in that (as of XrmToolBox version 1.2019.2.32 with Synchronous events execution order editor v 1.2016.8.23) lets you connect and set the rank on synchronous workflows (note that they only appear registered on the create event of the entity) but FAILS TO READ the existing rank out of the CRM correctly.

You can confirm the rank has been set by creating a solution, adding your workflow, then exporting.
Customizations.Xml contains (e.g.)
<StateCode>1</StateCode>
<StatusCode>2</StatusCode>
<Rank>50</Rank>
<RunAs>1</RunAs>
<IsTransacted>1</IsTransacted>



[Maybe see also...
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/entities/sdkmessageprocessingstep#BKMK_Rank
and the one sensible answer on
https://community.dynamics.com/crm/f/117/t/154063 ]

Virtualbox Copy and Paste not working - it's Excel?!

Just thought I'd post here since I've found no other hits:

I've used Virtualbox (on Windows) for years and copying and pasting (of text, anyway) always seems to have gone through phases of working consistently well or not working at all.

Anyway, I'm now running a Windows 7 VM on a Windows 10 host and 've noticed that the thing that breaks copy and paste appears to be using Excel on the guest machine.

After breaking it, killing and restarting vboxtray appears to work for about one copy and paste (but maybe only in the host->guest direction).   
Rebooting (just) the guest doesn't seem to fix it - I think I need to reboot the host as well (which I tend to do infrequently).

I'm still running with the obvious solution at the moment: avoid using Excel on the guest.

I was going to post this on a Samsung(USA) site where I found a thread, but it was so bloody awkward to create an account / sign in that I couldn't be bothered to complete the process.

Anyway

(SOLVED for me - posting just in case it helps) 

I've been having the wi-fi "internet not available" issue for a solid week now on my UK Samsung Galaxy S7.  Won't stay "connected" for more than a few minutes usage.  All other devices seem fine.

The problem appears fixed (or at least the phone has remained happily working for several hours) after I:

Firstly:  Went into settings -> apps -> (...) -> show system apps -> Bluetooth Share and first force stopped, then cleared data.   (I found this suggested as a solution elsewhere.  It did not appear to fix it for me - but I can't rule out the fact that it's involved.)

Secondly:  Went to my wi-fi router's config and DHCP-reserved an IP address for the S7's MAC.   I was careful to pick a *different* IP address from the one the phone was currently using.      Rebooted router (which was required to apply the reservation), turned off the phone's wi-fi (I was actually connected via a different access point, not directly to the router), turned the wi-fi back on once the router was available.

I confirmed that the phone had picked up the new, different IP.  No problems since!

Cheers.

It's always your ADFS certificates!

Despite the fact that the error message in the event logs for your Microsoft Dynamics CRM 2013 on-premise installation say...
28005
Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.

...you'll find when you finally enable tracing with the crmdiagtool that the error in the CRM logs instead says....

System.IdentityModel.Tokens.SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.

The solution (and you're even more annoyed because you've tried all the bits of it except clicking through the claims-based wizard in the CRM Deployment Manager:

Update the federated metadata on the two relying party trusts in ADFS manager;
Click through the claims-based authentication wizard AND the IFD wizard in CRM;
Restart ADFS Service;
Restart IIS;
(Try all 4 again if it still doesn't' work...)
and now you're all good!

Yamaha Clavinova CVP-8 power supply fault fixed!

My (previously parents') Yamaha Clavinova CVP-8 must be 25 years old now.  It had been getting into the habit of cutting out after it'd been on a while:  all the lights would go off and the buttons would be unresponsive, there'd be no sound from the keys but a gentle background buzz from the speakers.
If you turned it off and on again immediately then you'd get a gentle pop and all the same non-working symptoms, but if you left it off for a bit it tended to start working again, presumably as it cooled down.  However after a while it stopped the "starting working" again and was basically broken.

[Make sure you know how to be safe with mains electronics before you go doing this - there are dangerous voltages inside.]
Opening up the lid was a case of four screws on the underside, but the two at the rear are inaccessible while it's properly mounted on the stand just to make things more difficult.
Anyway, I'd found the power supply board with the big capacitors on it and I'd replaced those because I know that caps are often the thing that go bad in old electronics.  Unfortunately, this made no difference (though the piano did briefly start working again just to throw me off the scent).  FYI: The big cap in the bottom right of the board was charged to 20v and retained that voltage for at least a couple of days - nice big spark when I shorted it (so use a resistor)!

However, after another session of fiddling and some lucky turning on and off of the piano I worked out that my issue seemed to be that when it was working the machine had 2v or 4v (I think it was AC) measurable at (both sides of) the fuse towards the rear (using the metal heatsink case of that board as ground), and when it wasn't working it had 0v.    I traced the track on the underside of the PCB back to one of the end pins of the connector on the RHS of board - this was a wire directly from the big transformer, so I figured either the transformer was broken or... did that solder joint look slightly less than perfect through a magnifying class?  Turned out it was!  I resoldered all the joints on the bottom of the (what was it, 7 or 8 pin) connector and my Clavinova is working again!

PS  Credit to Yamaha for building a piece of kit that lasts this long.

(Other notes:  The rectifier near the connector gives out about 20v on the rear-right and the front-left pins.  I measure the cap of the (now replaced) big capacitor at the bottom right of the board and it was at 20v while the machine was on.  However,  the identical big cap next to it (by its "cap") was at 0v - not sure what that's about.  Off to the left two of the other 3 or 4 bigger caps were at 8v and 6v and the other two were 0v, I think.)