Archive
Windows Server 20xx Essentials cannot connect to O365.
I found this cheat to reset the connection between the Essentials Server Dashboard and O365.
First check the log to find out why it’s failing. Log file is found here:
C:\ProgramData\Microsoft\Windows Server\Logs\SharedServiceHost-EmailProviderServiceConfig.log
If log looks something like the below, then follow steps to fix:
BecWebServiceAdapter: Connect to BECWS failed due to known exception : System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at https://bws902-relay.microsoftonline.com/ProvisioningWebservice.svc?Redir=1098557810&Time=636356539931802459 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused
To fix:
Open Regedit and navigate to the following key:
HKEY_Local_Machine\Software\Microsoft\Windows Server\Productivity\O365Integration\Settings
Delete the BecEndPointAddress key.
Close Regedit and re-open the Essentials Dashboard. Re-attempt to integrate with O365 and this time it should work.
Resetting local Admin password for any Windows machine.
It’s kinda crazy how easy it is to crack a user’s workstation without ever logging onto the machine. It really means we should keep track of our local Admin passwords on our workstations and servers and after that lock down the BIOS so no one can re-arrange the boot order to be able to boot off a USB stick. When I worked at Microsoft, we developed a secured workstation that severely locked down the BIOS such that only the hard drive could boot – the key here was putting a password in the BIOS to prevent unauthorized changes.
However, there is at times a need to crack/reset the local Admin account password. This happened to me this week when I took over a client from another colleague of mine but the passwords for the Admin accounts were lost and since the users were just users (not admins) they couldn’t install anything nor make any system changes.
This procedure is out on the web too but thought I’d add my two cents.
Prerequisites:
1. Bootable USB stick – with Windows OS install or something else that will at least get you to a cmd prompt.
2. Access to BIOS to change boot order and allow USB to boot first prior to Operating System.
Setup BIOS to boot from USB first:
1. Boot up computer/server and use whatever Function keys to access the Bios.
2. Change menu option till you select BOOT. Then use keys to move USB boot to top of the line.
3. Save and reboot computer.
Change SETHC application to open cmd.exe application:
1. Insert bootable USB tool into port in computer.
2. System should select USB to boot first – if it didn’t try again and if still not, recheck BIOS settings to ensure Boot order has right USB set at top.
3. When setup screen comes up from USB, hit Shift+F10 to open cmd.exe prompt.
4. Locate the Drive C: or whichever drive letter has the operating system on it.
5. Change directories to get to c:\windows\system32 directory.
6. Type: copy c:\windows\system32\sethc.exe c:\sethc.exe * Note this makes a copy of executable file so you can copy it back after procedure is done.
7. Type: Copy c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe – This copies cmd prompt exe on top of sethc.exe (sticky keys application).
8. Reboot computer and remove USB from computer.
Change Admin Password:
1. At logon screen of computer, hit the Shift key a bunch of times, sometimes holding it down will do the same. The result will be a cmd.exe prompt running under the system context which gives access to reset passwords and do a host of other things.
2. To look for users type: net user – this will dump out list of users.
3. To reset password for say Admin account type: net user Admin password (substitute password for the real password. Should get a result of completed successfully.
4. Make sure the account you just reset password is active, to check type: net user Admin – it will show full status of account – look for attribute: Active – if says No… then you need to activate/enable it in order to use it.
5. To make active: net user Admin /Active:yes; Then check attributes again to ensure it’s active.
6. Now you can reboot back and access the machine using the admin account with password you just set, but you also have to go back with the USB utility to change the exe of sethc.exe back to it’s original function.
Reset System back to normal:
1. Reboot computer with USB inserted.
2. At setup screen, hit Shift+F10 to open cmd.exe prompt.
3. Change directory to c:\windows\system32
4. type: Copy c:\sethc.exe c:\windows\system32\sethc.exe – This returns original sethc.exe to copy over cmd application named sethc.exe.
5. exit and reboot computer and go back into BIOS to change boot order again to where Drive is primary (or whatever you would like).
Thanks.
Autotask Endpoint Mgmt splashtop remote tool fails to open from Agent Browser
I’ve been using Autotask Endpoint Management to monitor and manage my clients’ systems. Today I had a problem where my laptop was actually a part of another Autotask account and the change over to my account was pretty gnarly!
There should be a procedure for how to do such things but so far there isn’t.
Steps to take:
1. Remove account from instance of Autotask (one you’re leaving) delete the account and let it take it’s course in uninstalling on the client machine.
2. Should the second part not work, go to appwiz.cpl (short for Programs and Features) old Win95 reference to Add/remove programs. From there remove the Centrastage application.
3. Once all that is cleared up you should be able to install the new client agent from the new AEM Site.
Here’s where things went amiss.
I did all the above, not necessarily in the same order but got it done.
However upon step #3, the agent (system tray) would not start. Took a while to figure out that my AV/Firewall was blocking the application from starting.. Or another option is access to the c:\programdata\centrastage folder – but after checking Perms – they all seemed good and my account and System had Full Control.
Found a tidbit to run C:\Program Files (x86)\CentraStage\Gui.exe from a command prompt to let it run through it’s paces to get the Centrastage Tray working. With FW turned off and after running this the tray application could start.
However even with it running, I could not manage my client machines – the tool wouldn’t start the agent browser where you can then look at and open remote console tools…ugh
So decided to uninstall again and rip out all other parts of Centrastage application:
rmdir or just type: rd /S /Q “C:\Program Files (x86)\CentraStage”
rd /S /Q “C:\Windows\System32\config\systemprofile\AppData\Local\CentraStage”
rmdir /S /Q “C:\Windows\SysWOW64\config\systemprofile\AppData\Local\CentraStage”
rd /S /Q “C:\Users\%%f\AppData\Local\CentraStage”
rmdir /S /Q “%ALLUSERSPROFILE%\CentraStage”
reg delete “HKCR\cag” /f
reg delete “HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run” /v CentraStage /f
After, reinstalled everything and still not able to manage my client systems from the laptop.
Next decided to remove all the above again, and then remove all instances of Splashtop remote agents.
– Uninstalled Splashtop Streamer
– Uninstalled Splashtop Business Tool
Manually removed all splashtop folders found:
rd /q /s “C:\Program Files (x86)\Splashtop”
rd /q /s C:\programdata\splashtop
rd /q /s c:\%userprofile%\appdata\local\splashtop
Searched Registry for Splashtop items and removed things there as well (too many to list).
Did all that, and re-installed CentraStage application which in turn installed splashtop…
From there I was able to run the Agent Browser to connect to a device but when connecting to said machine using the splashtop plugin, Received a prompt asking which application to use to open the ST-Centrastage application… uh What? The only choice it gave you was to search the Microsoft Store… again What? What did I do to cause this behavior.
See picture:
The prompt states: You’ll need a new app to open this st-centrastage
with option to only look in the Store…
After much searching for st-centrastage and other… I was stumped and filed a ticket with Autotask folks.
Later in the day, decided to take a clean machine, join it to my AEM account and try to connect to a device using Splashtop. Before it could connect it prompted me stating it was missing the Splashtop Remote agent.. hmmm, said yes install it and then watched appwiz.cpl to see what application got installed – Sure enough MSP Remote Support by Splashtop was installed.
Went back to laptop and found the application was there but it couldn’t be uninstalled because I previously deleted all the Splashtop folders. Doh!
There are very few references on line for how to install this tool, there are plenty for uninstalling it but that doesn’t help when all the files are gone.
Ended up searching the registry for “MSP Remote” – started to delete all instances here as well so the connection program would later prompt me to re-install like on clean system above. As I ran through and found all the instances and deleted them, I came across one that showed the installer msi file used to install the application: LocalPackage – C:\windows\installer\43aee708.msi (different for every machine). So on laptop, went to that directory and ran the install. Rebooted and whoo hoo! success!
In a nutshell, to resolve transitioning from one AEM Instance to another
– Remove everything
– including the MSP application,
– then go back and remove the directories like above.
– then install the new AEM agent and attempt a remote connection (splashtop) if it fails with attached picture, search for the MSP Remote Support by Splashtop in registry to find the msi installer file to run and re-install this. without it you’ll go crazy looking for the solution. :).
Hope this helps.
JVH Consulting's Blog 