I have a FinalBuilder job that, as a final step, deploys the compiled app and DLLs to a network share on another server.
About 50% of the time, it just fails with
Win32 Error : The network path was not found
Changing the target from \\myserver\myshare to \\myserver.mydomain.com\myshare will often fix it temporarily - the first 2-3 runs after modifying the build file will work, after which it'll start failing again.
The FinalBuilder task is running with domain credentials granting admin access on the target box; and copying files to/from shares on that server via Windows Explorer works reliably.
I'm completely stumped.
Finally tracked this down. The target server was a virtual machine, and the Hyper-V host network settings were set to "Virtual Network" instead of "Virtual Teamed Network"
I have no idea what that means, but having changed it to Virtual Teamed Network, it works flawlessly. O_o
The network path was not found.
This is related to DNS/WINS not being able to look up the name. When I have seen this there are problems with our DNS servers.
Adding an Entry into the lmhost file would prevent the system from looking in DNS/WINS.
If that does not work, another option to consider is to increase the number of retries on the Action. This can be done from the "Runtime" tab of the action by clicking on "Timing Properties"
Related
We are using on site Dev-Ops and have a similar problem to that described in the link Example from SO.
But ours is intermittent.
Our environment uses two build and deploy machines, which each deploy machine having two worker agents.
For one of our projects, when it is deployed, we constantly get the error:
The VisualStudioRemoteDeployerc4d3852f-411b-48ba-97d8-5e09c8d07ce4 service failed to start due to the following error:
%%2
But here is the rub, not every time. Sometimes the deployment completes without error.
Other projects that use the same deployment machine and the same target server work each and every time without fail.
The deployment log reports "The WSMan provider host process did not return a proper response." as an error.
Checking the allocated memory, described in PowerShell Out of Memory, to find our set at 2.1 Billion.
This is an interesting issue that I have uncovered. The source of this problem stems from the interaction of McAfee Endpoint security.
Said antivirus was reporting that when the remote powershell script, using WSMan, was called. McAfee, saw this as a viral payload and canceled the deployment by stopping the service from running and deleting the payload. This has been reported to McAfee as an issue. In the mean time, internal network security settings for McAfee has had to be modified to ignore the processes used by powershell in remote deployment.
I had to change the name of the windows 7 system. Unaccountably, vncserver is still using the old computer name. This was RealVnc free version. I re-installed but it is still using the old computer name.
I had a Z400 motherboard go bad and it took the disk drive. I replaced the motherboard, $39 was cheap, and I cloned one of my other Z400 workstation C drives using Acronis. I booted the replacement motherboard with the cloned copy, changed its name to the old defective one, and activated windows. When It rebooted, vncserver still had the old computer name and I cannot get rid of it and it is conflicting with the vncserver on the other Z400 since they both use the same name. There is no option in the server to use a different name that I can find anywhere.
IPs are different and all system behave fine. I can ping and even access shares using their names. The problem system clearly shows the correct name but, unaccountably, vncserver is using the wrong name.
This system will be upgraded to 10 in a few days, maybe the problem will go away when that happens.
Solved! First I had to log in and reduce the number of clients to under 5 as that was my limit. Then I had to remove the problem system's leftover name. This was all done at realvnc web site. Once under 5 systems then I could add the problem one and once it connected to realvnc's cloud then it got the correct name. This was an artifact of having more then 5 systems when I was only licensed for 5. The "6th" one worked locally as its setup was still valid, but it was refused connection to the cloud so it never got to change its name. It "worked" until I did a flushdns and its old setup was no longer valid.
I'm trying to enable MSMQ on my development computer (running Windows 7).
I go to turn windows features on or off -> Microsoft Message Queue (MSMQ) Server Core -> Check MSMQ Active Directory Domain Services Integration AND MSMQ HTTP Support.
When I click OK, I get the error "An Error has occurred. Not all of the features were successfully changed." -> Click OK -> "You must restart your computer to apply these changes".
I've clicked Restart Now and Restart later and no matter what, same issue every time.
If I selected Restart later and go into Services...I see Message Queuing (stopped), and if I try to start the service, I get the error "Windows could not start the Message Queuing service on Local Computer. Error 0x80070005: Access denied."
I checked my privileges and I am an Admin on the machine. Just to be safe, I even logged into the machine as the actual Administrator. Same scenario.
Furthermore, when I go into the Event Viewer, I check the Application logs. I have an error with MSMQ as the Source. EventID: 2076, Error: The logger files cannot be initialized. The file QMLog in the Msmq\Storage folder is corrupted or absent. Error 0x80070005: Access denied.
If I check the System Logs, I see another error with the source being Service Control manager. Error eventId: 7023, Error: The Message Queuing service terminated with the following error: %%-2147024891
When I look up the error codes on Microsoft, there is NOTHING.
I had something like this - not sure how it came about as I always had AD integration turned ON for my MSMQ (as I needed it) but somewhere along the line, it got turned off and I couldn't turn it back on again via Control Panel - I would get the error behaviour (and restart!) that the OP describes. To fix it, I accessed my machine via the AD services manager app on one of our domain servers and deleted the "msmq" object that was under it.
I restarted my local MSMQ service on my machine AND rebooted (not sure which or both was required) and then when I checked my local registry entries, it indicated I was correctly running in AD mode once again. Everything started to work again after that.
This link was helpful in giving me the right direction to go in: Technet MSMQ delete stale objects article
Having a tough time with this issue. Not sure how but my ApplicationPoolIdentity is broken.
Currently I'm running IIS 8 on Windows 8 with Visual Studio 2012. When trying to debug an application from Visual Studio, or just navigating to the site in a browser I get the following error logged and a 503 error.
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
If I check out the Application error logs, I find the following error from the User Profile Service.
Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly.
DETAIL - The system cannot find the path specified.
Upon looking into the details I find that the User Profile Service is trying to load up a profile with the Id
S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415
Now I opened up the registry to try and find the profile with that UserId. However there's nothing in the Profile list that helps.
So digging around a little more I've found that this issue can be resolved by either
A) Set the Load User Profile of the Application Pool to false.
B) Use a different account for the application pool.
C) Fix the account.
Seeing how this is the built in account, I'd prefer to fix the issue rather than fix the sympton.
What I have tried
aspnet_regiis -i
Removing IIS from windows and reinstalling.
Attempted to follow the guide here but I don't know the account password :P
My hunch
Somehow the ApplicationPoolIdentity got messed up. Is there any physical folders for the built-in accounts? I know that the Network and Local service profiles physical directories exist at C:\Windows\ServiceProfiles\. It is possible to recreate the ApplicationPoolIdentity profile? Or am I way off on what the real issue is?
C) Here is what i did to fix the account
Go in regedit at key
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
There is a setting called "Default". You have to make sure that the data value point to an existing directory on the drive.
By default it contains "%SystemDrive%\Users\Default". In my company the default is changed to a custom profile. Somehow, someone deleted that user profile. So when the defaultAppPool user tryed to create an accound for himself, it was unable to do so because windows cannot provide him with a default user profile.
You can also diagnose this error when looking at the Event Viewer under the Application folder. You will get a message of that type:
Windows cannot find the local profile and is logging you on with a
temporary profile. changes you make to this profile will be lost when
you log off.
With TestComplete 8 we have a script that is scheduled to start 06:00 every morning by this line:
"C:\Program Files\Automated QA\TestComplete 8\Bin\TestComplete.exe" "C:\Attracs\TestComplete\Attracs\AttracsTEST\AttracsTESTProject.mds" /r /e /SilentMode
The problem is that this often fails. The log remark says:
An error occurred while calling the "Keys" method or property of the "TcxCustomInnerTextEdit" object.
The object or one of its parent objects does not exist.
If I connect to the computer with Remote Desktop and manually run the script it works fine.
There is no screensaver active and the power scheme is set to never sleep.
I have noticed that Testcomplete needs a handle to GUI (the screen is visible) or the script got this kind of errors. Could it be that when it starts it have no handle to the GUI components because they aren't visible ?
From the helps Running Tests via Remote desktop:
However, if you minimize the Remote Desktop window (the window that display the remote computer’s desktop), the operating system switches the remote session to the GUI-less mode and does not display windows and controls. As a result, TestComplete (or TestExecute) is unable to interact with the tested application’s GUI, as the GUI does not actually exist in this case and your automated GUI test fails.
To avoid this issue, you can keep the Remote Desktop window visible during the test run, but this may be inconvenient as it occupies some part or even your entire screen and leaves less space for you to run your local applications.
Any solution for this?
There is a way to enable the console connection in Windows to be active at all times, which allows TestComplete to work without actually connecting with RDP.
From: Running Tests in Minimized Remote Desktop Windows
Log in to the computer from which you
connect to remote computers.
Close all open Remote Desktop
sessions.
Launch the Registry editor
(Regedit.exe).
If you have a 32-bit operating system:
Locate the
HKEY_CURRENT_USER\Software\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for the current user only.
-- or --
Locate the
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for all the users.
Create a new DWORD value in this key
and name it
RemoteDesktop_SuppressWhenMinimized.
Specify 2 as the value data.
If you have a 64-bit operating system:
Locate the
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for the current user only.
-- or --
Locate the
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal
Server Client\ Registry key if you
want to change the connection settings
for all the users.
Add the
RemoteDesktop_SuppressWhenMinimized
value to the key.
I found this page
http://www.automatedqa.com/support/viewarticle/12567/viewarticle.aspx?aid=12567
It seems that a solution could be that running TestComplete in a Virtual machine.
/Roland
To run any UI test, the UI needs to be available. Hence, the machine should be unlocked so that TestComplete can perform user actions like mouse click, keys, etc to work.
However, if you have non UI test like running Web Services then it will work.