Core Problem
The problem I am having is that connectivity to Exchange from Outlook is blocked while executing an integration test through the Microsoft Test Agent (i.e. Outlook is in the disconnected state). The test is launched through Microsoft Test Manager.
Below is the code for the integration test I am having problems with and I simplified the code as much as possible to rule out code within the integration test causing the problem. I also eliminated all other tests from running.
[TestMethod]
public void LaunchOutlook()
{
Process.Start(new ProcessStartInfo(#"C:\Program Files (x86)\Microsoft Office\Office14\Outlook.exe"));
Thread.Sleep(120000);
}
I can change how long Outlook is blocked by changing the Thread.Sleep timeout. While the test is running, I can restart Outlook and Outlook is still blocked. After the test ends while Outlook is still running, connectivity to Exchange is restored. This happens for Outlook 2010 and Outlook 2013. If I run the integration test within a console app, Outlook connectivity is not blocked. If I run the test code manually through MSTest.exe, Outlook connectivity is not blocked. The only way it’s blocked is if the integration test is executed by the Microsoft Test Agent which is the required approach for integration testing.
More details on the problem
Outlook is running on a machine that is part of a Hyper-V Lab with network isolation enabled. There are other machines within the same lab that have Outlook instances pointed against the same Exchange server. Executing the test on one machine causes Outlook connectivity issues with other machines within the same lab where the Outlook instances are pointed at the same Exchange server.
I have small Hyper-V lab with network isolation enabled which is very similar to the lab mentioned above. The major difference is that it only has one machine with Outlook installed. This Outlook is able to connect to Exchange while executing the test above through Microsoft Test Manager. It is very clear that this is an environmental issue since it works in one lab and not the other. Both labs have the same Exchange server installed, and the same Microsoft Test Agent installed on all machines within the lab.
I have ruled out the Outlook version as being the issue since the larger lab contains the same Outlook version as the Outlook version in the smaller lab.
During test run
Notice that Outlook is in the disconnected state.
After test run.
Notice that Outlook is not connected to Exchange.
Environment Information
Outlook 2010 Version: (14.0.7113.5000) SP2 (14.0.1740.5002) 64-bit or 32-bit
Outlook 2013 Version: (15.0.4667.1000) MSO (15.0.4675.1002) 64-bit or 32-bit
Windows 7 Version: 6.1 (Build 7601: Service Pack 1)
Exchange 2013 Version: 15.0 (Build 847.32)
Windows Server 2008 R2 Version: 6.1 (Build 7601: Service Pack 1)
Microsoft Test Manager 2013 Version: 12.0.31101.0
TFS 2013 Update 4 Version: 12.0.31101.0
Microsoft Test Agent Version: 12.0.31101.0 Update 4
Troubleshooting Steps
I launched procmon and looked for failed TCP and UDP operations for indication of network failures and found none.
I turned on enable troubleshooting logging in Outlook and nothing within the logs looks obvious.
Pinging the Exchange server while the test is running still works.
I ran the integration test through the command line using MSTest.exe and outlook connectivity is not blocked.
Requesting Help
Can you please help me troubleshoot this problem? I see two approaches to identifying the problem.
1. Looking for differences between the two environments
2. Obtaining logs or other information that would expose the core problem.
I am open to suggestions or ideas especially if you have a different approach to solving the problem. Feel free to ask for other information related to the problem like logs, PowerShell commands, and registry values.
If you are short on time, can you at least post some suggestions or ideas related to resolving this problem?
Thanks,
Keith
After installing fiddler I figured out what the problem was. The Microsoft Test Agent was activating a proxy server which was blocking connectivity to exchange. The proxy server was activated due to having the ASP.Net Client Proxy for IntelliTrace and Test Impact turned on.
Below is a link to the article with the exact same problem.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ecc0b342-8e4d-436c-90c2-5f11bce1e9d8/proxy-server-settings-being-set-automatically-which-is-causing-me-not-to-be-able-to-run-manual-test?forum=vsmantest
Related
Unlike the test tool for Windows 10, which is part of the Windows 10 SDK, Microsoft went out of their way to make the certification tool for Windows Server 2016 complicated.
I installed my test application and specified the path to the Inno Setup installer, off the Downloads folder, and specified the location of the binary files, namely the Program Files location, and the screen shown, I specified the process name, basically the executable file name. At least System Internal's Process Monitor utility said that was the name.
As you can see, I got thrown an error.
Log Time: 12/04/2018 08:57:21
MethodName:: ApplicationRunningViewModel.VerifyApplication
Message:
No running application's process found after your application installation.
==================================================================
Log Time: 12/04/2018 08:57:58
MethodName:: ApplicationRunningViewModel.VerifyAppProcess
Message:
Process not found in snapshot file.
==================================================================
How do I resolve the error? Basically, how is the steps to use this test tool?
Background:
I had previously certified my application for Windows 10 in the Windows Platform Ready / Winqual area of Microsoft and obtained the Microsoft Gold Application Development competency.
I was expecting to simply pay the yearly extortion fee, $5400, when I logged into the portal, saw the new redesigned Partner Center, and went to the Competency Summary section, where I saw the message that I am in danger to lose the competency. Microsoft apparently did away application certification based competencies for Application Development. Talking to MS external support, I was told what I already saw on my own that the Silver ISV is the only path forward testing against Windows Server 2016. My attempts to talk to a real Microsoft employee or find a real solution failed miserably. I think talking to Google is easier. I hope that MS straightens things out for next year. By the way, the Platform Ready / WinQual area disappeared as well as all certifications.
That brings me to my question. I am trying to use the Windows Server 2016 test tool (2019 was not available last week for download, hence 2016).
I already installed the application. It works fine on Windows Server 2016, just Microsoft did not make application verification easy.
How do I resolve this error? What piece of information does it want and how do I obtain it?
I found the same error while testing my application using the Certification Test Tool 1.0 for Windows Server for Windows Server 2019.
I just changed the sequence of the test. I did launch the tool and then installed my application. If you cancel the test your application must be reinstalled in order for the test tool to recognize your process. Everything worked as expected
I got another error while using the Certification Test Tool Preview for Windows Server 2016. He couldn't validate my signed assemblies because the tool verify the aseemblies signature usign the signtool.exe instead of sn.exe. If you signed your assemblies using the sn.exe, neither of the test tools for Windows server 2016 & 2019 will validate your signed assemblies. I had to check the log file generated by the test tool and sign the assemblies manually using the signtool.exe.
I hope this information help someone havign the same issues.
Greetings
I recently had to uninstall/re-install .NET Framework 3.5 on my new Windows 10 work machine to troubleshoot another issue. I have to install it via SCCM due to Group Policy blocking Windows Updates (so I can't just install via Control Panel > Turn Features On/Off).
When attempting to re-install through SCCM the install just spins in the Installing state indefinitely until it times out.
Steps taken:
Uninstalled the .NET 3.5 Framework via Turn Windows Features On and Off in Control Panel and restarted machine.
Went to SCCM and attempted to install software, and it hung indefinitely.
After 2 hours I restarted machine to check if I just wasn't alerted it was finished for some reason
Install did not finish, Failed status shows with the error code for timeout in SCCM.
Other Info:
I verified no errors were generated in the SCCM log files or Event Viewer.
I can't install via Control Panel MS Update download as mentioned above due to Group Policy, I can't do an Offline install b/c these laptops don't have a disk drive (for whatever reason that was decided to be ok), and I can't do a system restore to before I removed it due to drive encryption software.
No admin accounts or similar can get different results, and I've verified it is not the SCCM install itself after getting it to install on another machine just fine.
I've ran both the .NET Framework Repair tools and Clean-up tools and I still get the issue.
Any ideas on what I can try?
If anyone encounters a situation similar, I was able to fix it by extracting the microsoft-windows-netfx3-ondemand-package.cab file from the .iso of Windows 10.
Using that file you can run the following script in an elevated (administrator) powershell and it will install the files offline for you.
Dism /online /enable-feature /featurename:NetFX3 /All /Source:<path to file>
I have an Outlook Add in where I am using Microsoft.Office.Interop.Outlook.Storageitem to save my settings.
Most of my tests access the settings to set or get the configuration for contacting the server.
On my local machine all of the tests are running fine. But when I check in my project into TFS and run the tests there all of them fail with the Error:
System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
The error occurs when the test is calling the following codeline.
Folder inbox = (Folder) new Microsoft.Office.Interop.Outlook.Application().GetNamespace("MAPI").GetDefaultFolder(OlDefaultFolders.olFolderInbox);
I asume that the error appears because the test tries to access an Application of Outlook and does not have the permission.
Outlook is instaled on the Windows Server 2012 where TFS is running.
Also Outlook was started once with having no Mailaccount configured. (The test runs fine when i start it manually on a machine with a Outlook with no Mailaccount configured.)
The C:\Windows\SysWOW64\config\systemprofile\Desktop folder exists.
I already have set all permissions for the user NETWORK SERVICE in Controlpanel->Administrative tools->Component Services->computers-> myComputer->DCOM Config->Microsoft Outlook
I also found this question which has no answer to my problem.
Are there any other steps i could try to give my tests access to run the tests sucessfully?
Outlook is instaled on the Windows Server 2012 where TFS is running.
I already have set all permissions for the user NETWORK SERVICE in Controlpanel->Administrative tools->Component Services->computers-> myComputer->DCOM Config->Microsoft Outlook
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
No Office app (Outlook included) can be used in a service. I don't think actually creating an instance of Outlook.Application is a good idea in a unit test.
Try changing the TFS build server to run as a user with admin rights on the box. I would not suggest leaving this configuration.
I deployed a web role in windows Azure, based on the following tutorial.
http://weblogs.asp.net/scottgu/archive/2013/10/22/windows-azure-announcing-release-of-windows-azure-sdk-2-2-with-lots-of-goodies.aspx
but when I try attaching the debugger I get the following message:
"there was a failure to launch the remote debugger"
apparently this is a known issue, and the suggested solution from Microsoft is to restart the visual studio and try again, which unfortunately didn't work for me
http://msdn.microsoft.com/en-us/library/windowsazure/dn459835.aspx
Remote debugging may fail to attach to an existing Cloud Service:
After deploying a new Cloud Service the debugger may fail to attach to
an existing cloud service with the error message “There was a failure
to launch the remote debugger”. To correct this problem, restart
Visual Studio and reattach the debugger to the new deployment.
So I thought to ask here in case anybody faced the same issue and found another solution other than restarting the visual studio!
I'm using visual studio 2012, with Azure SDK 2.2
Make sure that you deployed a Debug build to your web role and that you have checked "Enable Remote Debugging for all roles" on the advanced tab during deployment. Failure to do either of these could lead to the problem your seeing.
I was using Azure SDK 2.2, so as to use "Attach debugger", but unfortunately I needed to use SDK 2.1 as 2.2 needs some references that weren't included in 2.1, so I guess this is the problem.
Thank you all for your help
I tried all of the solutions above and found that none worked for me. My problem turned out to be stale or inaccessible certificates that the VS debugger uses to connect to the service. I discovered this was the problem by going to event viewer and found:
A fatal error occurred when attempting to access the SSL client
credential private key. The error code returned from the cryptographic
module is 0x8009030D. The internal error state is 10003.
I had had other problems with permissions on private keys and so I ended up deleting all of the certificates from my personal store (current user) with the "Issued To" equal to "Windows Azure Tools". When I redeployed my service VS created new certificates and uploaded them.
Voilà -- attach remote debugger works again.
I got the same exception trying to remotely debug a VM in Azure, following the guide in Debugging Azure Virtual Machines.
What worked for me was to simply install the remote debugging tools matching my version of Visual Studio (VS2013 Update2).
Further I had to add a new endpoint in the Azure portal. This didn't work initially but eventually using the same public and private port number did the trick. The default port of 4018 worked.
Start the remote debugger program on the client machine in adminstrator mode and remember to set to port number, e.g. to 4018. I chose Windows authentication as well.
From within Visual Studio: Debug menu -> Attach to Process -> [yourVMName].cloudapp.net:4018 or whatever port number you chose. You should now see a list of processes on the virtual machine.
In case its helpful for someone else, I've just spent 3 hours on this! In the end I gave up and using 'Cloud Explorer' (in VS 2013, after installing the Azure SDK) I selected 'Disable Debugging' and noticed it cleared out port rules in the Network Security Group for the VM.
I hadn't seen it set these up (which is where I'd spent hours guessing that these were the issue and trying to figure them out from patchy MS documentation, broken links, etc).
So, I 'enabled debugging' for the VM and saw it set up security rules - something it didn't do the first time!
At a guess this is because I had initially enabled debugging for my VM soon after I installed the Azure SDK into VS. Since then I rebooted the VS server, and that may have enabled something in the SDK.
Anyway - before spending hours figuring out ports, reboot the VS server and then disable/reenable debugging in Cloud Explorer - you should see a status message (in the Azure Activity Log) saying 'Configuring networking security group debugging port' - this is the magic step that it didn't do the first time around.
I think you should try lunching VS in administrator mode, and see if you always have the same problem.
Else I think you should put more details about your problem.
This is what I did to enable debugging on an Azure VM.
At the time of this writing my current setup is as follows
Windows Server 2012 R2 IIS 8.5 (Virtual Machine)
Visual Studio 2013 Update 4
Microsoft Azure SDK Tools 2.5
Update Visual Studio to the latest Azure SDK
go th the server window (server explorer)
Expand the Azure node
Expand the virtual machines node
Right click on the VM you want to debug
Choose "Enable Debugging" Visual Studio will begin to add a debugger extension to your virtual machine
Once complete, Right click on the virtual machine from the virtual explorer and choose attach debugger
My company recently using tivoli workload scheduler (TWS) to remote trigger jobs from an z/OS to window server. we have tested the tivoli can trigger the mssql services successfully.
The problem now is we have a .NET CL program that we used daily to extract some data in AS400 to mssql server, it was worked perfectly before when using windows scheduler and trigger daily in specific time frame. now we trying to centralize the scheduler so the TWS remotely trigger a prepared batch file (it will trigger the CL program).
but the execution of the CL program show following error while trying to connect to AS400 DB.
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
EDITED:
in normal scenario, we were assumed the program can trigger successfully, it should be just like using windows scheduler, set a schedule and execute it. the only differences is the scheduler is not windows scheduler for now, but switch to TWS and trigger the CL program remotely. but the execute show the above error during executing the CL program. we have no idea why this error comes up.
we tried to rerun the CL program and schedule it in windows scheduler, works fine. but schedule on TWS remotely, error.
For the testing and observation we have done so far:
Our server is Windows server 2008 SP2 x64, I have made some researches the MDAC used in old version windows while server 2008 should deliver with a newer version of MDAC (WDAC 6.0) and it cannot be reinstall so i assume the MDAC/WDAC must be install correctly.
the CL program was compiled with .NET 2.0/ 3.0 / 3.5, and tested all of them produce the same error.
they error logs were able to produce to sql server DB, so I assume the connection driver using in CL program have no problem. but it might be caused by IBMDA400 driver.
TWS use the admin account in our server to trigger the batch files, a TWS client (listener) is installed in our server for trigger programs in our server, but we dont know how they connect to our server (SSH? telnet?) and they seems donot actually login to our server for remote trigger(trigger our job in silent mode).
we are desperate in seeking any solutions, if anyone could provide any clues or thoughts, it would be very helpful and provide a big help to the people with the same problem in the future.
Thank you very much!.
For those searching, I recently got this error in a web app despite MDAC 2.8 SP1 being already installed on the 2008 box. We re-installed MDAC and it did not seem to fix. Stopping and starting the app pool for the affected web app fixed the problem. It's not 100% clear if the re-install was necessary, or if windows updates or something required an iisreset that didn't happen.
The reason for this error is that the application pool is trying to read a registry key from the HKey_Current_User hive which isn't always loaded.
The solution is as follow:
Open IIS management console
Click on "Application Pools"
Right-click the pool for your web site and select "Advanced Settings"
Change the setting "Load User Profile" to True
I can only give you some avenues to investigate.
You may want to try using the IBM DB2 iSeries ADO.NET Data provider instead of using the IBMDA400 OLE DB provider. My team had a similar experience when we went through a re-platforming project to a newer Windows Server that was x64. For some reason we had very strange results trying to use the older OLE DB providers on our .NET Windows Services. We later found out it was due to our server being 64bit.
I am suspecting you are having an issue with the IBMDA400 is a 32bit driver. Check if you are compiling your .NET CL program as 64bit. You could try to compile your program as a 32 bit application and enabling Wow64 on your server.
Hope one of these leads you to a solution!