After both resetting the Vivofit and the mobile it still didn’t work correctly, I got permission to join the troubleshooting

Since she just created her Garmin account and I don’t use one, I thought, let’s give it a shot on my Honor 8 mobile, a little older, but still pretty much like her new shiny p10 lite. After removing the Vivofit from her app(and turning off bluetooth on her mobile?) it wanted to be added to my Garmin app. On my mobile the setup went right through and looked a lot better and the display design changed, but I think the important part was that it now discovered a firmware update. Once it had updated, I removed it from my app and uninstalled it. Then I tried connecting it to her P10 lite and this time it went through correctly and the display design changed to her preference and syncing seems to work.

During this troubleshooting (trouble was the Synology – looong sad story) I’ve had to reboot the hosts numerous times and every time I’ve been forced to shut down the network ports on the switch, that holds the iSCSI kernels’ network ports, otherwise the hosts wouldn’t boot it would just stay up and look as if it was waiting for a timeout. It might be that this timeout would’ve occurred if I had waited long enough, but I found myself patiently waiting for 10-20 minutes it seemed at the time… Suddenly I read and understood the message it was giving me: My set up is I’m running 3 Storevirtual datastores with Network-RAID10, 1 without Network RAID and 3 Synology datastores. When I wanted to reboot, I shut down the VSA appliance on the host and all my VMs were moved to the other host – but the issue was that since I had 1 datastore without Network RAID, this goes offline whenever I shut down any 1 of my VSA appliances.

This creates the issue, that the ESXi host cannot tell that volume that it is going down for a reboot and for some reason this is bad for the host – even though there is nothing using that datastore on the host. The VMs that have a VMDK on that datastore just shouldn’t use data to or from that VMDK while it’s offline and then there is no issue. The problem is that I cannot turn on the network ports again, until the host is completely booted because it also MUST for some reason connect to this offline volume under start-up, it just stays saying starting up ISCSI in the ESXi boot screen. If I keep the ports offline, the host boots quickly and then I can turn on the VSA appliance and the network ports and do a rescan of the iSCSI adapter and it’ll connect to the datastores – but it sometimes has the error message “All shared datastores has failed” on the Summary page.

To me this seems like a design problem and it would seem to me that a lot of people could have this potential issue/bad experience if using volumes without Network-RAID10?

So for later reference, as it took some minutes to find these specific activation IDs, I’ll list them here to find them more easily next time KMS makes trouble

Check licensing status: cscript slmgr.vbs /dlv “activation id”
Re-activate KMS licensing: cscript slmgr.vbs /ato “activation id”

Re-activate Office on clients:
C:\program files(x86)\Microsoft Office\Office15\cscript ospp.vbs /act

Activation IDs:
Windows2012R2_Win10 activation id: 20e938bb-df44-45ee-bde1-4e4fe7477f37
Office 2010 activation id:bfe7a195-4f8f-4f0b-a622-cf13c7d16864
Office 2013(OFFICE15) activation id: 2E28138A-847F-42BC-9752-61B03FFF33CD

http://www.hihonor.com/de/support/details/?DOC_ID=77508

When you unzip this, there’s a “dload/update.app” folder/file that needs to be placed at the root of an SD-card and then through the EMUI updater application, you choose Local update, then it will find the file and update to Android Marshmallow in about 10-20 minutes, first parts of the update ended with a “post-process failed” error and then booted in to the upgrade optimizing part and then the update was done.

After a few updates and a little getting settled time, the phone seemed OK, I did a reboot just to clean up and everything seems to run fine.

To be able to audit logon events throughout our organization we have enabled the usual audit policies in the Domain Controller group policy:

At some point someone decided to audit if there were happening changes to our audit policies, through the “Advanced Audit Policy Configuration”. This additional audit policy was made through the Group Policy Management Console on a Windows 2012R2 server. Here it’s possible, without issues or hints that it’s a bad idea, to make this policy. When this got enforced on domain controllers, they stopped logging the above events in their security event-logs. This made it impossible to help users that got locked out without knowing where from and why, because the typical “bad password” events did not get logged. This is where you get the client ip of the session that is giving the bad password, mostly because it’s been hanging around since before the user last changed their password.

If you look on technet, sure Microsoft mentions that if you enable both the audit policies and the advanced audit policies, it can cause odd behaviour – https://technet.microsoft.com/en-us/library/dd692792(WS.10).aspx

If the admin had looked and wondered about the explanation Microsoft put in the policy configuration, he would/should have made the change that is required to have both Audit Policy and the Advanced Audit Policy Configuration:

Here it tells you to enable the “Audit: Force audit policy subcategory settings (Windows Vista or later)” under Windows Settings/Security Settings/Local Policies/Security Options. 

After the new server was brought up and was prepared, I tried again to use the remote tools to administer the server, but to my “horror” I was still getting this error… Now with the upgrade, I went for a 2012R2 version where the old was 2008R2, so I started thinking if there could be an issue with this for the new server. At the time I didn’t have other remote 2012R2 domain controllers, so for a while I settled with this and decided to come back and try to resolve it when I got some spare time – the DC was running perfectly on all other measures.

Today, a little over a month later, I got this extra time on my hands and decided to give it another look. Now, since last month, I’ve got a brand new site that holds a 2012R2 DC and of course this works fine with the remote tools – so something had to be messed up on the other site. I tried a quick search for RPC and RSAT tools and got some old Windows Vista KB that didn’t help me much, but then the second result took me in the direction, that some antivirus clients(or rather the Realtime-scan part) had a tendency to block RPC calls – so I tried to unload the Officescan client and voila -> The connection in ADUC switched over to the server that it couldn’t connect to previously…

Now this is all fine and dandy, but what I cannot get around is – how can it work against the other site’s DC without any issues???

The only thing I see different between the 2 sites is that the brand new site is VPN connected through Cisco ASA, and the other site that needs me to turn of Officescan is connected through our company MPLS…

If anyone can explain this to me – please do so in the comments below!

/
Dan

This can be handled through the Exchange Control Panel website, where an admin can turn it off for the specific users.

But now mom has been upgraded, and she really only uses Microsoft Solitaire collection, 1 game-site online with Java-games and occasionally browse the net. She found that when playing the Spider solitaire game, she could force the crash message and her game needed to be restarted, but she could never get a game done.

Having this to search from, I quickly found that a lot of other people are playing these games and they have seen many issues with these since Windows 10 came along. But in November, Intel finally stepped up at least on the beta channel – and provided what seems to be a fixed display driver, still though on the release notes, there are quite a few games that have issues, so be careful to read this.

Find the Intel beta download here: https://downloadcenter.intel.com/download/25541/Intel-Beta-Graphics-Driver-for-Windows-7-8-1-10-15-40-

This driver seems to work for most Intel current display adapters, but check the list below:

Intel® Iris Pro Graphics 5200 for 4th Generation Intel® Core Processors
Intel® Iris Graphics 5100 for 4th Generation Intel® Core Processors
Intel® HD Graphics 5000 for 4th Generation Intel® Core Processors
Intel® HD Graphics 4600 for 4th Generation Intel® Core Processors
Intel® HD Graphics 4400 for 4th Generation Intel® Core Processors
Intel® HD Graphics 4200 for 4th Generation Intel® Core Processors
Intel® HD Graphics 5300 for Intel® Core M Processors
Intel® Iris Graphics 6100 for 5th Generation Intel® Core Processors
Intel® HD Graphics 5500 for 5th Generation Intel® Core Processors
Intel® HD Graphics 6000 for 5th Generation Intel® Core Processors
Intel® HD Graphics 530 for 6th Generation Intel® Core Processors
Intel® HD Graphics 515 for 6th Generation Intel® Core M Processors
Intel® HD Graphics 520 for 6th Generation Intel® Core Processors
Intel® Iris Pro Graphics 580 for 6th Generation Intel® Core Processors
Intel® Iris Graphics 540 for 6th Generation Intel® Core Processors
Intel® Iris Graphics 550 for 6th Generation Intel® Core Processors
Intel® Iris Pro Graphics 6200 for 5th Generation Intel® Core Processors

First I created a Sandbox environment from the existing Zendesk setup we have, this is a great feature to test out new additional functionality without disturbing users and agents.
Once this was set up, I followed Zendesk own ADFS setup guide:
https://support.zendesk.com/hc/en-us/articles/203663886-Setting-up-single-sign-on-using-Active-Directory-with-ADFS-and-SAML-Plus-and-Enterprise-

This worked fine for the initial setup, but still something was not working, so I contacted Zendesk Support and hoped they could help. They pointed me in the direction that my fingerprint which is setup in the Zendesk interface was wrong:
In the requirements for ADFS and Zendesk to work, they state:

To me, this says that the SSL-cert I have on my ADFS login page is the one I need for my fingerprint value. From Zendesk support I got the first 4 digits of what they thought my fingerprint should be, that wasn’t correct either. But alas after asking Twitter – @MrADFS came to my rescue:

@danevald The thumbprint to configure on the Zen Desk side should be the token signing cert and not the SSL cert.

— Samuel Devasahayam (@MrADFS) August 20, 2015

This is pretty easy to find in ADFS 3.0 at least, run this on the ADFS server:
Get-ADFSCertificate –CertificateType “Token-Signing”
I took the thumbprint from here and copied it to my Zendesk settings and now it worked.
Another “issue” I was faced with, was that my production-Zendesk site, wasn’t running SSL, and this is required for getting SSO to work.

The way this works can be in 2 ways:
– If you are OK with your users seeing the true URL of you Zendesk, then they are just forwarded from the CNAME you’ve configured to yoururl.zendesk.com and switched to SSL here.

– If you want to stay at helpdesk.yourdomain.com, you have to provide Zendesk with a public SSL-cert, which can be bought at any cert-provider. The cert-request and deploy process is all done through the Security settings in Zendesk.

For me option 1 was OK, and I just switched on Regular SSL and ADFS now works.

On the Spiceworks forums this showed up:

And with that little tweak in compatibility settings, now everything looks great again.