We have a third party vendor running a program/service on my servers. We need to monitor that process and see if that process is using a lot of memory or dumping/uploading lot of data or accessing any other process/stuff that it is supposed not to access.
What is the best possible way to do this? Since it is a prod box, we are not supposed to install any software on the server. So, any default tools (like Regmon/Filemon) that comes with Win 2003 would be great. But, if there is no tools that can help, I can get persmissions to install s/w.
tldr; need to keep an eye on a process using default windows tools. What is the best way??
Any help/pointers is greatly appreciated.
Thanks.
As a first regmon and filemon does not comes with any windows version neither desktop nor server edition.
It is product of sysinternals (M. Rusenovich) currently are covered by MS, but not bundled in any version of OS.
Standard tools are called performance counters and are available through manage computer context menu on "My Computer" icon, or just by running perfmon.exe or perfmon.msc
You can setup exact what you want to track.
Related
Last Thursday I was asked to code fairly small app for an Android device and I went with React-Native. The app is now in the testing phase (it's really small) and I was asked again if we could also deploy the app on a Windows machine.
I code exclusively in Linux, but I also know about NW.js which does produce an output for both Linux, Mac and Windows regardless of the environment, so I said : "Sure! I'll see what I can do!"
But reading the react-native-windows' documentation, I'm not sure if that's possible. At least it is not clear to me.
So the question is not really "can it be done?" but rather "how can it be done?" I could request a Windows machine if I have to, but if I can avoid it I'd rather not go there because that would mean maintaining two computers where one'd be used only for that purpose, etc.
Edit : Basically, I am wondering if it is possible to generate an executable JAR archive of a React-Native project which then can be launched from any Java-supported desktop computer.
We are trying to setup Eclipse CDT (version Helios or Indigo) for our development environment. It is a multiuser environment, with about 100+ designers using a pool of 10 linux servers. The source code is in Clearcase.
Developers has Windows PCs and use vnc to login to development servers.
One option is using different Eclipse installation on each Windows desktop - but then not sure how complicated setup is to enable remote code browsing/compile/debug/test execution or cross compiling. Is this going to be a IT support/maintenance nightmare?
The other option is to have a single copy of Eclipse on the server and everyone uses the same one. Hoe feasible is this? How difficult is to manage different users' preferences in this setup? Is it possible to have that (different setups) at all? What about required hardware configuration to support this kind of working environment - when multiple sessions are active on the same server at the same time? Is this kind of configuration going to scale?
Which option is better/more suitable for our environment? Any other option that we should consider?
I checked this question and it is useful but not sure about specific of the development environment that they were trying to address.
I would like to hear some experiences from anyone who managed to successfully set it up in a similar development environment (or tried to do it) and would appreciate any guidelines/recommendations in this regard.
I'm having a lot of trouble getting SharePointRS_x64.msi to install sucessfully says it cannot find sharepoint when in fact that sharepoint is installed and running on Win 7 Pro. Because of the operating system I am unable to install the prereq package that comes with SharePoint Foundation 2010 (which includes this reporting addin).
I already have a reporting server set up for my MSSQL2008 instance(win 2008 server R2). It's working when I go to the http:\servername\Reports i'm able to launch the report builder and everything works. I'm now having trouble setting up the other end on SharePoint (different (developement) machine - running win 7 pro).
Any Help would be GREATLY appriciated.
Please let me know if what I want to do is possible.
Thanks,
Mike
I found the solution.
You need to open config file:
C:\Program Files\Microsoft SQL Server\MSRS10.\Reporting Services\ReportServer\rsreportserver.config
In this config find string:
Add Key="SecureConnectionLevel" Value="2"
Change value 2 to 0.
Values meaning:
3 - Most secure-Use SSL for absolutely everything.
2 - Secure-Use SSL for rendering and methods that pass credentials but don't insist on it for all SOAP calls.
1 - Basic Security-Accepts http but rejects any calls that might be involved in the passing of credentials.
0 - Least Secure-Don't use SSL at all.
You have to remember that installing sp2010 on your desktop is going to limit your farm. It is not going to be a fully functional farm. Advanced features like search and user profile sync will not work/get buggy. I guess now, you can add reporting services intergration to the list of things that don't work. Safe your self a lot of trouble but building a vm, which is going to be closer to your production environment anyway.
UPDATE
I thought it might not be supported by Foundation, but it is:
http://msdn.microsoft.com/en-us/library/bb326356.aspx
I inherited a huge code base which was written to work on Windows XP. Now we would like to migrate to Windows 7. I do not know what is the proper way to go about this. What is the proper approach to do the above task? I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
Usually how do S/W developers migrate their code/apps written for one version of OS say Vista to Windows 7?
I sell an autoupdate solution (AutoUpdate+, minor plug) and so have lots of experience porting Windows apps to the latest releases, and yet still maintaining backwards compatibility. Porting from Windows XP to Windows 7 can be a big challenge (there should be almost no difference in a move from Windows Vista to Window 7).
Window XP doesn't care where your application exists, and hence programmers would dump both their application and support logic (log files, config files, user profiles etc.) into the same location under "C:\Program Files\". Take this application to Windows 7 and you'll start finding some unusual behaviors. For starters, you will notice that files seem to 'disappear'. Instead of a log file being modified under the common Program Files location, you may end up with multiple, and separate, copies for each user under "Compatibility / Program Files". Windows Vista/7 introduced file system virtualization, and will now create separate user instances of files to ensure to ensure that each user has their own secure copy.
Another problem you will encounter on Windows Vista, and to a lesser extent on Windows 7, is User Account Control (UAC) prompts. It's similar to the issue above, in that new security restrictions will now cause Windows Vista/7 to prompt the user for approval to proceed. The most noticeable area where this occurs is when you are tampering with executable files in sensitive directories, installing applications and drivers, and sometimes when trying to self-update an app (the abovementioned app actually works around these prompts with some smart logic).
So in short, security changes are the biggest difference between Windows XP and Windows Vista/7. Your best start is to separate application logic (binaries) from supporting logic, by putting the latter into user specific directories. Some apps may never be fixable and can be forced instead to work in Compatibility Mode or to launch always under the Admin account context --- poor workarounds, but may be suitable in your company.
Simon # http://AutoUpdatePlus.com
There are three parts to the migration. First, make it just plain work. This means fixing up hardcoded file paths (there's no more Documents and Settings), changing some of your save locations so you don't need to be elevated to work properly and don't rely on virtualization, changing some of your registry key locations for the same reason, and coping with high-DPI which might now be applied automatically based on screen size rather than as a user's choice.
Second, make it look and work like a Windows 7 application. Is your jumplist usable? Your thumbnail? You get some things for free, do you like what you get or would you like to take control? Are there obvious wins you could use like thumbnail buttons, jumplist tasks, taskbar overlays, etc. Don't surprise your users and don't disappoint your users. (Example of disappointment: VS 2008 and the crummy jumplists it offered. They had the excuse of being released before Windows 7 - you don't.)
Third, take advantage of Windows 7 to be greater than you otherwise would. Stop polling for network joins, file creation, hardware being plugged in, going on and off AC power etc and learn how to get notified when those things happen. Add touch support beyond what you get for free. Talk to a sensor or GPS for the first time, since Windows 7 makes it simpler than it ever was. That sort of thing.
1 is not optional. 2 is really not optional either, a year after Windows 7 is released. 3 will differentiate you and I recommend, once you get past 1 and 2, you look into it.
Basically Windows7 is a 4bit OS and so necessarily runs on a 64bit processor environment. XP has 32bit as well as 4 bit flavours. If your application is for the 32bit version of XP, in that case, the major migration means making the application run on 4bit OS effectively.
The basic steps can be something like this:
Make it compatible to 64bit win7. So you may just compile the code off a win7 machine (on 64bit). If the compilation works fine, you might be able to run the app successfully.
The first step just allows to move ahead. But your application might not be effective. In that case, you might have to review the code for any specific implementation coupled on 32bit os and upgrade them to take advantage of 64bit OS.
The major advantages on 64bit OS is higher address-ability (so access more RAM) and also cache etc.
I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
API diff report between XP and Vista: https://abi-laboratory.pro/compatibility/Windows_5.0_to_Windows_6.0/x86_64/abi_compat_report.html
API diff report between Vista and 7: https://abi-laboratory.pro/compatibility/Windows_6.0_to_Windows_7.0/x86_64/abi_compat_report.html
The reports are generated by the abi-compliance-checker tool.
Many of my users have been telling me that they'd like to run my software on their Linux machines under Wine.
But I'm a Windows Developer who has practically no experience with Linux.
Now I could spend a month or two installing Linux, learning Linux, installing Wine, learning Wine, and thoroughly ensure my application runs well under Wine. But I am still developing for Windows, so I don't want to take so much time away from development right now.
So what can I do without too much effort to get my program running as well as possible under Wine?
I did find this General help on running applications under Wine.
Download VMWare and an Ubuntu virtual machine (Ubuntu is a popular Linux distribution) from the VMWare site. This will provide you with a working Linux O/S inside your Windows environment without needing to install Linux manually.
You can then use the instructions here to install Wine, that Wiki page also provides you with some instructions on how to use it.
If you follow what Adam Rosenfield suggested and just try running your application in Wine unmodified, you will be able to determine quickly whether there are problems. My guess would be that there are some, otherwise your users would not have contacted you about it :)
There are many ways for getting help with debugging applications in Wine, consult the website for options and pick a few ways that suit you. As always, it's best not to rely on a single channel for communication.
Also, if you are more comfortable with developing in Windows, the approach of using a virtual machine will allow you to compile your code as usual in Windows and copy the binary into the virtual machine for testing (Ubuntu supports browsing/mounting Windows shares).
As long as you're not doing anything unusual such as playing around with hardware or poking around in undocumented API calls and data structures, you should be able to run your code under Wine with few or no modifications. Wine has a fairly complete implementation of the public Windows APIs, so if your program plays nice and doesn't mess around, it should just work.
Don't use too much of the windows API! Don't use anything new from Microsoft ;)
Avoid using WPF is the #1 suggestion.
But it really wouldn't kill you to test your app under Wine. It's not that hard to try; it certainly won't take months. For instance:
Use http://www.ubuntu.com/getubuntu/downloadmirrors#wubi to install
Ubuntu into a file on your Windows machine, then start ubuntu and install the latest Wine from
http://winehq.org/download/deb
Then try running your app's installer.
If it doesn't work, check the Wine FAQ, ask for help in one of the wine forums, and/or file bugs in wine's bug tracker.
Should take about three hours from a dead start to trying out your installer.
I was rather surprised when one of my Delphi5 applications just worked out of the zip.
The only real way this is going to work is to do it yourself, i.e. install vmware and a linux distro as Sean suggested. Linux isn't actually that hard, and we're all here to help.
Having done a quick test I can confirm that it largely works. There is an ACCVIO reading 0x34 during start up, the error dialog can be ignored and the application runs, I opened the Steve McCarthy GEDCOM.
Screenshot
This was using Wine 1.1.12 under MEPIS 7.9.94-rc1_32 under VMWare. Highly recommend to use VMWare for this sort of thing.
What language/platform do you develop with? Depending on which it is, it should be no trouble to get it running native. For example, if you use Java or Python, both operate very cleanly on Linux. Likewise, if you're a .NET developer, you should be able, with some pain, to get your app running in Mono.
Find Linux beta testers. It can reports a bug to WINE developers or find a bug in your application.
Wine is more sensitive to errors than Windows. For example, Wine will crash on NULL window handles, and fail to create windows if the class is invalid, whereas Windows is more robust and will just circumvent the error.
It's an opportunity to clean up your code.
I was amazed at how well Wine ran my app the first time I tried. However, I had to get rid of a third-party driver-based component.