I'm wondering if XP supports persistent shadow copying like Windows Vista/7 do. I read the wikipedia article about Shadow Copy and it had this paragraph (emphasis mine):
The creation of persistent snapshots (multiple snapshots which remain
available across reboots until
specifically deleted from the system)
has been added in Windows Server
2003, allowing up to 512 snapshots
to exist simultaneously for the same
volume. In Windows Server 2003, VSS is
therefore used to create incremental
periodic snapshots of data or deltas
(differences) of changed files over
time. A maximum of 64 snapshots are
stored on the server and accessible by
clients or on the same server through
network shares. This feature is known
as Shadow copies for Shared Folders
and is designed for a client-server
model. The Shadow copies for Shared
Folders client is required to be
installed on Windows 2000 and Windows
XP RTM and SP1. A copy of this client
for 32-bit Windows platforms is
available on the server or
downloadable from Microsoft. It is
built into the OS beginning with
Windows XP SP2.
I interpreted this as XP having the ability to create persistent Shadow Copies, or partial copies of a file that exist even when the network connection is broken.
If you can shed some light on the supported functionality I would appreciate it.
XP does not support persistent Shadow Copies, so you must supply a script/app to call back if you use the sample client, or create the shadow copy and work with it in the same process in case you use the API.
Related
Can I install Visual Studio Code on Windows server 2008 ?
I am a developer but I sent the information to my administrators and they told me that the setup file crashes after launched
I get seput file from hee https://code.visualstudio.com/download
procesor: Intel(R) Xeon(R) Gold 6142 CPU # 2.60Ghz - 2.59 GHz
RAM: 8 GB
64-bit
virtual machine
1 CPU - 2 cores
Windows Server 2008
First time answering here so bare with my vintage reply formatting. (also pardon that i couldn't capture screen due to server is on a intranet that not accessible on this device causing a long reply)
Being a unfortunate fellow that need to work on legacy Systems and Application frequently, i happen to have a fresh 2008R2 server recently setup by my team's Server Admin with following specs:
processor: Intel(R) Xeon(R) Gold 5220 CPU # 2.20Ghz - 2.19 GHz ,
OS: Windows Server 2008R2 x64 ,
RAM: 8GB
The versions that is able to install was 1.70.3,which is the same version that is the last supporting versions for Windows 7 as well,if you happen to need to work on devices using that OS version.
although i'm uncertain whether it is a VM or not, i'd like to point out a few more things that your question did not cover but need to consider:
The installer version (System setup vs User Setup)
aside from the x64 |x86 | ARM installer differences, as you've not mentioned which versions of the build and which exact setup installer you sent to your admin, i've first replied which build version successfully installed on 2008R2, which as of writing the latest build was 1.73.0 and on run,it pop up a error message as follow regardless of System/User Setup:
This Program does not support the version of windows your computer is running.
in our current case that we want specific previous versions installer, VScode FAQ on previous versions have a URL lists that enables you to download a specific build version of your preferred setup. For my case (and also refer below to exactly why this one), i've go for System setup, and i know the aprox. supporting version was ~1.70.0, so i used the link as below and replace the {version} to start:
https://update.code.visualstudio.com/{version}/win32-x64/stable
Active Domain, Multiple user sessions etc.
Per VSCode requirements page stated,
VS Code does not support multiple simultaneous users using the software on the same machine, including shared virtual desktop
infrastructure machines or a pooled Windows/Linux Virtual Desktop host
pool.
as im not sure do you work solo or do have fellow colleagues to code on the server at the same time, you might need to reconsider to install using user or System setup.
if your intentions are to use exclusively on a specific AD account, then user setup should probably be good enough.
however, if the intentions was to setup say a shared Remote desktop connections on the VM that allows multiple RDC sessions simultaneously for coding,programming etc., so you intend to install a system setup to allow all users on said server to be able to use VScode, then you might run into the problem the VScode requirements stated it does not support.
in addition, as i was remote connected as administrator , when using a 1.70.2 user setup ,a different warning message as follow was thrown:
This user Installer is not meant to be run as Administrator. If you would like to install VS Code for all users in this system, download the system Installer instead.Are you sure you want to continue?
as the installer itself also checks with the operator on this matter, your admin may have skipped on the exact reasons why the install failed and just told you the installer crashed.
if you absolutely need VScode to run on the server but can't install for reasons, the last resort (aside from going for alternatives like notepad++) is to Setup a Portable Mode builds on your own workstation/devices first, then upload the package to the server and use it from there.
i wouldn't go into too much detail in that as this reply already span for a starwars trilogy length but keep in mind, version limitations still apply, and whatever add-ons you need, you need to download them first before bundle it into the package to upload and run on your server.
Anyone that is a System admin or infrastructure architects , do correct me on my novice understanding on Server settings etc. as although i'm primarily a programmer, i did end up touching a lot more things that i'm not specialized into over the few years of vendor career work so there bound to be incorrect/inaccurate concepts i spilled. cheers.
Using Firebird 2, we had to deploy 3 files with our applications to be able to connect to remote firebird servers:
fbclient.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest
The first file was retrieved from the "normal" Firebird installer, the other 2 files from the "embedded" installer.
Firebird 4 doesn't provide an embedded installer, and I don't find proper information what to deploy for clients.
Reading this: https://ib-aid.com/download/docs/fb4migrationguide.html#_installing_client looks like Firebird 3 has lower demands. Is that the case? I just need communication-encryption and longer passwords, so FB3 would also be fine. (BTW, following the guide didn't bring success, otherwise I would not ask).
The minimum necessary files are listed in the document you link:
If we speak about installing Firebird client only, you need to have
fbclient.dll file. Firebird 4.0 client requires Microsoft Runtime C++
2017 with the same bitness as fbclient.dll. If Microsoft Runtime is
not installed, you may just copy it’s two files, msvcp140.dll and
vcruntime140.dll that are included in ZIP for Windows.
So the absolute minimum you need is fbclient.dll, and in some cases you may also need msvcp140.dll and vcruntime140.dll when those are not already installed on your system.
In addition, it is advisable to include firebird.msg for error messages, and for some use cases, adding the ICU files is advisable (if you use the functions of fbclient to render/parse WITH TIME ZONE types).
If you want wire compression, you'll also need zlib1.dll, and if you want to use Chacha wire encryption instead of the less secure ARC4, then you also need plugins/chacha.dll (the chacha.dll needs to be in a plugins folder relative to fbclient.dll).
All these libraries must be the same bitness as your application. As discussed in the comments, the problem seems to have been that you tried the 64-bit DLLs from a 64-bit Firebird installation, while your application was 32-bit.
If your application is 32-bit, then obtain the files from a 32-bit installation or zip kit, or look in the WOW64(*) folder of a 64-bit installation (from the installer, the 64-bit zip kit doesn't contain this directory). This WOW64 folder contains the 32-bit files fbclient.dll, msvcp140.dll and vcruntime140.dll (for the additional DLLs you need to use a 32-bit installer or zip kit).
* This follows the awkward Windows naming of 64-bit Windows having 64-bit files in %WINDIR%\System32, and 32-bit files in %WINDIR%\SysWOW64
First off I used to be an XP guy and I still have the copy that I bought back in 2002. I had to downgrade my computer to an old iMac I had in storage and the only copy that I have of XP (I really do not want to buy a new one) is the old copy. I installed into a fully formatted drive and then realised that this XP disc came out before service pack 1. Which means that there really is no support for this. Next I noticed that the ethernet driver is unrecognized (big shock) therefore I have no internet, so I cannot install using windows update. Therefore I do not have any updates (again this disc is very old) and no access to the internet.
I have another computer that I can burn discs off of and it has the internet but I will not have it for much longer.
The device I installed the XP on is an 20-inch iMac (Early 2006), 2.0 GHz Intel(R) CPU T2500 with 1.98GB RAM
Is it possible to update my machine and be able to do use it the way it should be?
How I managed it was that I downloaded found an executable version of SP1a and then updated the system by moving the file over, then I downloaded the service pack SP3 ISO, updated the system.
However it didn't fix the ethernet driver and since I had no idea what the controller's actual name nor the company that made it, I moved over the Auslogics System Information, did a diagnostics took the problem devices "Value" and did research in order to find the needed information, and got the driver and moved it over. Yay monotony.
I want to deploy a client application that uses Oracle's ODP.net but I don't want to install ODP.net on every machine. Rather I'd like to copy the managed dll oracle.dataaccess.dll on every machine and have the native dlls on which it depends available, on a shared disk.
By decompiling the oracle.dataaccess.dll code I have seen that it calls a method that gets the location of the native dlls from the registry. So, in addition to copying the oracle.dataaccess.dll on every machine I would have to add the registry keys that would point to the native dlls on the shared disk.
My question: does one foresee any problem arising from that technique of odp.net deployment?
The only files you need from the latest client are:
Oracle.DataAccess.dll
oci.dll
oraociicus11.dll
OraOps11w.dll
Just make sure they get copied to the output directory and everything will work. Nothing needs to be registered anywhere. You will however need to make separate x86 and x64 builds with the respective architecture's DLLs since an Any CPU .NET application will run in 32-bit mode on a 32-bit OS and in 64-bit mode on a 64-bit OS.
1) ODP.NET is currently a mixture of managed and unmanaged DLL's. It also relies on lower level unmanaged DLLs from the Oracle client - eg for networking, etc.
2) You will need all these required ODP.NET and client DLLs on each machine you deploy to.
3) One potential solution to make this easier on you is to look into the "XCOPY" deployment package. See the ODP.NET download page. This is a smaller install and allows you to write your own custom installer. You can include these XCOPY files as part of your own install.
4) Oracle will be doing a beta of a fully managed provider in 2012 which will make this situation much better (and the total size will be a couple megabytes only).
Christian Shay
Oracle
Since they're unmanaged I'd assume that they'd be ok on a network path, though that should be easy enough to test. However I'd suggest that rather than changing the registry setting, you might be better off changing the DllPath config setting as described here.
I'd like to use alternatives to System Center Virtual Machine Manager 2008 is possible, in other words, any FREE tools?
Before SCVMM, Microsoft's solution was the Virtual Server Migration Toolkit. This requires Windows Server 2003 Automated Deployment Services, which in turn can only be installed on Windows Server 2003 Enterprise Edition. It's about as far from a free tool as you can get. It only works on SP1, not SP2 (unless ADS has been updated since I last checked), and you have to obtain all the patches you've applied to the physical system.
ADS is limited to four partitions per physical disk, because it can't create extended partitions. If your physical system has more than four partitions you have a problem.
Once you do have it running, though, it does actually work.
Many disk copying tools like Ghost or True Image can now produce .vhd files from a physical system.
Google "Pysical to virtual conversion" or P2V. There are several solutions available. Unfortunately it sounds as though not many have had success with Microsoft's solution.
Try the following:
1. Download and install the VMWare Converter and follow the instructions to convert the physical machine.
2. Download the VMWare to VHD conversion utility from VMToolkit.com and convert the image.
This didn't work for me when I tried it last week, but I think it is because the drive I converted used PGP.
Use VMWare its not free, but you can get a decent 30 day trial, which should be enough to do your conversions. VMWare also has other great advantages if you're willing to pay for the product.
First, backup the physical system to an image, and convert it to a virtual disk which can be directly used in a virtual machine.
See this article.