Server 2008 R2 Domain Controller MMC Crashes when Adding Role - server

I've searched around and have not been able to resolve my issue. The only thing I haven't tried yet that I've seen suggested is copying MMC Registry entries from a working server, mainly becaue I do not have an identically configured working server to copy from and don't really want to go through the trouble of creating one unless that is really my only option.
As stated in the title, I have a Server 2008 R2 domain controller that I am attempting to add the Active Directory Certificate Service role to. When I open the add role dialog, MMC crashes immediately after selecting the checkbox for the AD CS role. It does not crash if I select the checkbox for any other not yet installed role. If anyone has any suggestions, it would be greatly appreciated. I have deleted the cache as suggested in other forums. I have verified .net installations with the verification tool from Microsoft. And I have run the sfc tool, no errors were reported.
As I am not an IT guy by trade, if anyone is willing to assist me, I'll gladly re-run through any suggestions I've already tried or provide any additional data that may be helpful. Thanks.
Here is the text from the server manager log regarding the crash:
3208: 2017-10-04 16:01:20.927 [CBS] IsCacheStillGood: True.
3208: 2017-10-04 16:01:32.315 [Provider] System changed since last refresh: False
3208: 2017-10-04 16:01:34.062 [CAManager] Test Initialization: CCertSrvSetup
3208: 2017-10-04 16:01:34.202 [CAManager] Test initialization: True
3208: 2017-10-04 16:01:35.388 [CAManager] Initialization: Creating CCertSrvSetup
3208: 2017-10-04 16:01:35.404 [CAManager] Initialization: Initializing defaults
3208: 2017-10-04 16:01:35.435 [CAManager] Initialization: Getting default key information
3208: 2017-10-04 16:01:35.435 [CAManager] Initialization: Getting existing certificates
3208: 2017-10-04 16:01:35.466 [CAManager] Error (Id=0) An exception occurred at at Microsoft.CertificateServices.Setup.Interop.CCertSrvSetupClass.GetExistingCACertificates()
at Microsoft.Windows.ServerManager.CertificateServer.CAManager.UpdateModel(Boolean certificateAuthorityAdded). Exception: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'
And this is the text from the problem details dialog when the crash occurs:
Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: mmc.exe
Problem Signature 02: 6.1.7601.23892
Problem Signature 03: 5990c6ab
Problem Signature 04: mscorlib
Problem Signature 05: 2.0.0.0
Problem Signature 06: 58e46330
Problem Signature 07: 4227
Problem Signature 08: a9
Problem Signature 09: System.AccessViolationException
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

Well, I haven't been able to solve the issue with MMC. BUT, after digging around and piecing a variety of things together, I was able to install the role via some Powershell scripts. It appears to be installed and functioning at this point. I am now going to try to generate my SSL Certificates and wrap this all up. There were a few other things that I tried previously, but the one that seemed to do it for me was found here.

Related

ERROR running force:package:version:create: Invalid character in header content ["getApiVersion"]

a. If the Dev Hub org doesn't have its "Unlocked and 2GP Packages" option enabled, you would get the error message Invalid character in header content ["getApiVersion"]. You may want to check that
b. This can be also caused due to lack of permissions on the user performing the operation. If you are using a Limited Access User Profile for performing the job and then make sure following permissions are part of your profile.
Create and Update Second-Generation Packages
Promote a package version to released
c. The error is might be also caused due to the custom code, please reach out to your internal developer to verify the same to investigate this further.
In my case it was the option c. Adding here to help the community

Why does BitBake error if it can't find www.example.com?

BitBake fails for me because it can't find https://www.example.com.
My computer is an x86-64 running native Xubuntu 18.04. Network connection is via DSL. I'm using the latest versions of the OpenEmbedded/Yocto toolchain.
This is the response I get when I run BitBake:
$ bitbake -k core-image-sato
WARNING: Host distribution "ubuntu-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
The networking issue, the reason why I can't access www.example.com, is a question for the SuperUser forum. My question here is, why does BitBake rely on the existence of www.example.com? What is it about that website that is so vital to BitBake's operation? Why does BitBake post an Error if it cannot find https://www.example.com?
At this time, I don't wish to set BB_NO_NETWORK = "1". I would rather understand and resolve the root cause of the problem first.
Modifying poky.conf didn't work for me (and from what I read, modifying anything under Poky is a no-no for a long term solution).
Modifying /conf/local.conf was the only solution that worked for me. Simply add one of the two options:
#check connectivity using google
CONNECTIVITY_CHECK_URIS = "https://www.google.com/"
#skip connectivity checks
CONNECTIVITY_CHECK_URIS = ""
This solution was originally found here.
For me, this appears to be a problem with my ISP (CenturyLink) not correctly resolving www.example.com. If I try to navigate to https://www.example.com in the browser address bar I just get taken to the ISP's "this is not a valid address" page.
Technically speaking, this isn't supposed to happen, but for whatever reason it does. I was able to work around this temporarily by modifying the CONNECTIVITY_CHECK_URIS in poky/meta-poky/conf/distro/poky.conf to something that actually resolves:
# The CONNECTIVITY_CHECK_URI's are used to test whether we can succesfully
# fetch from the network (and warn you if not). To disable the test set
# the variable to be empty.
# Git example url: git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=master
CONNECTIVITY_CHECK_URIS ?= "https://www.google.com/"
See this commit for more insight and discussion on the addition of the www.example.com check. Not sure what the best long-term fix is, but the change above allowed me to build successfully.
If you want to resolve this issue without modifying poky.conf or local.conf or any of the files for that matter, just do:
$touch conf/sanity.conf
It is clearly written in meta/conf/sanity.conf that:
Expert users can confirm their sanity with "touch conf/sanity.conf"
If you don't want to execute this command on every session or build, you can comment out the line INHERIT += "sanity" from meta/conf/sanity.conf, so the file looks something like this:
Had same issue with Bell ISP when accessing example.com gave DNS error.
Solved by switching ISP's DNS IP to Google's DNS (to avoid making changes to configs):
https://developers.google.com/speed/public-dns/docs/using

Sugarcrm 8 XSRF

I've backup of ondemand instance for sugarcrm version 8.0.0 Enterprise Edition
It works normal for CRUD records and other stuff, but when I try to upload module via Zip it gives me following error
Cross Site Request Forgery (XSRF) Attack Detected
Form authentication failure (Administration -> UpgradeWizard). Contact your administrator.
I've tried following article
Troubleshooting Cross-Site Forgery Messages
But the problem still persists. The problem only occurs for BWC modules IMO.
EDIT: Before trying this work-around, check if you have the HTTP referer header disabled in your web browser, as that might be the reason for having the described problem in the first place.
If this is a local test/dev-instance you might want to add
['csrf']['soft_fail_form'] = true,
to your $sugar_config in config.php or config_override.php. That should cause the error to be logged only instead of aborting the action.
Note: This works on Sugar 7.9. I have yet to test it on 8.0.
Source: https://community.sugarcrm.com/community/developer/blog/2017/10/11/upcoming-security-changes-to-sugar
Add this lines in your config_override.php file
$sugar_config['http_referer']['list'][] = 'http://CHANGE_TO_YOUR_LOCAL_URL/';
$sugar_config['csrf']['soft_fail_form'] = true;

[error]Process 'appcmd.exe' exited with code '87'

I am new to tfs-2018, I am trying to do deploy on one of my servers but getting below error in the log. I was able to deploy on other 2 systems but one system is giving the bellow error. Any help will be appreciated
Log:
2018-01-29T06:55:20.8002862Z ##[section]Starting: IIS Web App Manage
2018-01-29T06:55:20.8484384Z ==============================================================================
2018-01-29T06:55:20.8484384Z Task : IIS Web App Manage
2018-01-29T06:55:20.8484384Z Description : Create or update a Website, Web App, Virtual Directories, and Application Pool
2018-01-29T06:55:20.8484384Z Version : 0.4.4
2018-01-29T06:55:20.8484384Z Author : Microsoft Corporation
2018-01-29T06:55:20.8484384Z Help : More Information
2018-01-29T06:55:20.8484384Z ==============================================================================
2018-01-29T06:55:24.2725407Z ##[command]"C:\Windows\system32\inetsrv\appcmd.exe" list app "Default Web Site/PDM"
2018-01-29T06:55:24.4872952Z ##[command]"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/PDM" -[path='/'].physicalPath:"E:\inetpub\wwwroot\PDM" -[path='/'].userName: -[path='/'].password:
2018-01-29T06:55:24.7066288Z APP object "Default Web Site/PDM" changed
2018-01-29T06:55:24.7066288Z ERROR ( hresult:80070057, message:Failed to commit configuration changes.
2018-01-29T06:55:24.7998202Z
2018-01-29T06:55:24.7998202Z The parameter is incorrect.
2018-01-29T06:55:24.7998202Z
2018-01-29T06:55:24.7998202Z )
2018-01-29T06:55:25.1905059Z ##[error]Process 'appcmd.exe' exited with code '87'.
2018-01-29T06:55:25.3169881Z ##[section]Finishing: IIS Web App Manage
Below is the configuration details attached.
I had similiar symptoms at one Windows Server 2012 R2 - on all other Windows Server 2012 R2 it would work.
Symptoms
"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/foo" -applicationPool:"foo" -[path='/'].physicalPath:"C:\temp\foo" -[path='/'].userName: -[path='/'].password:
ERROR ( hresult:80070057, message:Failed to commit configuration changes.
The Parameter is incorrect.
)
We tried to figure out what was happening, and found that the appcmd.exe password Parameter would not work.
When omitting the password parameter the command would work fine:
"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/foo" -applicationPool:"foo" -[path='/'].physicalPath:"C:\temp\foo" -[path='/'].userName:
Another symptom that led us to the root of the problem was:
specifying Physical Path credentials for a VirtualDirectory via the mgmnt-console would also not work.
Solution
For us, the problem was with a corrupt IIS Configuration Key. That prevented us from encrypting passwords in the applicationhost.config
We fixed the problem by importing the IIS Configuration Key from another test-machine.
Reinstalling IIS would have worked as well (if we ever had that problem on a production server)
Exporting the config key from a working IIS Server:
aspnet_regiis -px "iisConfigurationKey" "C:\temp\iisConfigurationKey.xml" -pri
Importing the config key at the renitent IIS Server:
aspnet_regiis -pi "iisConfigurationKey" "C:\temp\iisConfigurationKey.xml"
Replace AesProvider Element
Finally we replaced the AesProvider Provider Element from applicationHost.config
configProtectedData Section with the element from the working IIS Server and restarted the IIS.
Buried in there you will see The parameter is incorrect. which is what Microsoft’s standardized error code 87 means.
In my case the list of urls was wrong (I wasn’t delimiting them correctly with colons, or the wildcards were incorrect). Looking at yours, I don’t see an equivalent field. But try simplifying the fields you have specified until you get something working, then add the real values back gradually.

SSO Bad Data Error

I'm running BizTalk 2013r2 CU5 in Win2012r2
I noticed a file wasn't being collected from a receive location. The relevant host instance was running, so I checked the event log and found this:
SSO AUDIT Function: GetConfigInfo
({E182FB76-16B4-47D7-8178-4C66C9E3BA9D}) Tracking ID:
c4d0d0d1-0763-4ec5-99ea-fb2ac3bcc744 Client Computer: BizTalkBuild01
(BTSNTSvc64.exe:7940) Client User: BIZTALKBUILD01\BizTalkSvc
Application Name: {E182FB76-16B4-47D7-8178-4C66C9E3BA9D} Error Code:
0xC0002A1F, Cannot perform encryption or decryption because the secret
is not available from the master secret server. See the event log for
related errors.
I then restored the master secret using:
ssoConfig -restoresecret SSOxxxx.bak
After restoring, the file is still not being collected but the error messages in the event log have changed to this:
SSO AUDIT Function: GetConfigInfo
({2DC11892-82FF-4617-A491-5324CAEF8E90}) Tracking ID:
5e91d09d-1128-491b-851b-e8c8e69d06eb Client Computer: BizTalkBuild01
(BTSNTSvc64.exe:26408) Client User: BIZTALKBUILD01\BizTalkSvc
Application Name: {2DC11892-82FF-4617-A491-5324CAEF8E90} Error Code:
0x80090005, Bad Data.
Does anyone know of a solution to this please? This is the 2nd time I've faced this problem on different servers in the last 3 months.
The MSI for CU6 has now been fixed
For BizTalk 2013 R2 this may be a known issue, with a hotfix available!
There is a hotfix for this issue, however, the hotfix may introduce another issue (memory leak). A solution can be found here: https://blogs.msdn.microsoft.com/amantaras/2015/11/10/event-id-10536-entsso-bad-data-issue/