Prior to upgrading UCM from 7.1.2.6 to 8.x we need to amalgamate the vobs on a windows server to a common vob sever on aix.
However it appears we have a bit of a Siamese twin set up that from the Windows Region I can already see both sets of VOBS.
When checking, The existing vobs on AIX and Windows share a common ADMIN PVOB (aix).
In Project Explorer Both sets of vobs share a common PVOB and both sets of components are visible together.
I am therefore wondering to move the VOBS (.vbs) from windows to AIX server should I be able to move the vbs across to aix then when I do the various reformats and protects and re do the hyperlink to the admin vob that it should all knit back together?
The existing vobs on AIX and Windows share a common ADMIN PVOB (aix)
That means after dumping (db_dumper/db_loader) and/or reformatting the Vob from Windows to Aix, you should not have to "re do the hyperlink to the admin vob": they should already be there, in the new (moved) Vob.
Related
I do laptop provisioning at home and something I use at the end is the DJOIN.exe command so the laptops will be ready for use when connecting on our offices' network.
Typically if I want to do an offline domain join, I will use:
DJOIN /REQUESTODJ /LOADFILE .\[filename] /WINDOWSPATH C:\windows /LOCALOS
On most laptop models this will execute fine and allow users to login to their Windows accounts once they're on the office network. I'm working with a new model today (thanks supply chain issues!) and even though it is also running Windows 10, I am getting the error message:
/LOCALOS specified but the current OS does not support domain join functionality.
The request is not supported.
Doing a google search for that exact message shows there are no results and most of the other results aren't for offline joining specifically as they include steps on the DC side of things -- which don't apply here since it's an offline join. I tried it without the /LOCALOS flag just to see what happens and it gave me:
/REQUESTODJ only operates on an offline (not running) Windows image
by default. The path supplied [C:\windows] is the current running Windows
installation. To override the default behavior and target the currently
running local operating system also specify /LOCALOS.
The parameter is incorrect.
Has anyone else encountered this and know why/how this happens and how to get past it? I didn't see any hints generated in Event Viewer; hoping to avoid a bunch of tickets down the line asking for domain joins once they've reached the office š
MAJOR facepalm here.
Just posting this so there's a reference for others, but this batch of laptops have Windows HOME installed on them, not Pro. Per this page with Home vs Pro features, Active Directory / Domain Joining is not supported on Windows Home. Either install Pro on the laptops or return them and purchase a batch with Pro on them.
I am working on an installer of a windows application. Due to its dependencies, to make it work, multiple applications need to be installed and also some changes to the windows features (turning on some windows features) are required.
My installer is supposed to be used by companies. In companies, it can be the case that someone has the rights to install software (in program files folder) but is still restricted (for example updates are regulated by the IT department). A typical explanation for this is that someone is a local admin but not necessarily a global admin.
Can it be the case that someone is allowed to install software in the program files folder but restricted in enabling windows features? I need to know this because this would simply mean that my installer should not automatically/automated enable such windows features. It may work on my VM, but it can fail on the customer employee desktop which would cause the installation to fail due to missing rights for one specific action: enabling some windows features.
Can enabling Windows Features be blocked for local admins?
According to this answer there's no group policies to control Windows features. Therefore we could assume that you're safe for now.
I have successfully captured an image using sysprep and can provision new machines from it, however all the custom user settings are missing (desktop shortcuts, chrome bookmarks etc...).
A more serious issue is that one of the applications I had installed fails on the provisioned machine unless run as administrator (due to the way it writes some files when being installed originally).
How can I ensure this profile information is preserved and I don't hit the permissions issue for the application?
I have been pointed at the following link (http://theitbros.com/sysprep-xp-sp3-copy-administrator-profile/) but it seems to be Win XP specific.
Profile information can be migrated to a new deployment using the User State Migration Tool (USMT). USMT is a free tool designed to help IT Professionals migrate files and settings to Windows 7 or Windows 8. USMT captures user accounts, user files, operating system settings, and applications settings and then migrates them to the new Windows installation. The TechNet articles āStep-by-Step: Basic Windows Migration using USMT for IT Professionalsā and āUser State Migration Tool 4.0 Userās Guideā are good places to start learning how to use USMT.
For your application issue, I would recommend using the Microsoft Deployment Toolkit (MDT) for your deployments. MDT can deploy your image and then install device drivers and applications to the machine automatically. These two video walkthroughs are specific to migrating from Windows XP to Windows 7 with MDT, and using USMT to migrate the user files and settings:
Part 1: Building the Deployment Environment
Part 2: Initiating the Install and Migrating the PC
There is also a Microsoft Virtual Academy 7 part course titled āMigrating from Windows XP to Windows 7ā that has two parts dedicated to using USMT to transfer user data and one part for MDT.
MDT can be downloaded here, and USMT is a part of the ADK which is a component of MDT.
Hope this helps,
The answer here wasn't very elegant (in my mind at least) but here is what I did to achieve the desired result:
Create the VM as usual (specifying the admin user during setup)
Create a new (non-admin) user and give them RDP access
Log in as the non-admin user
Install all the necessary software
Log in as the admin user, change the permissions for any files that were causing an issue to be readable by the non-admin user
Run sysprep as the admin and complete the process as detailed elsewhere
This gave me an image that I was able to provision VMs from. When creating the VM I specified the admin user to be created (but then never needed to login as the admin, as I would just login as my non-admin user that was created before). All profile settings for the non-admin user are preserved.
Hope this helps anyone else facing the same issue.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In āper-machineā installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.
We have an application that stores its database files in a subfolder of the Program Files directory. These files are redirected to the VirtualStore in Vista and Windows 7. We represent data from the database using Microsoft DataReports (VB6). So far so good.
But we now want to use Crystal Reports XI to represent data from the database. Our idea is to NOT pass this data to CR from our program, but to have CR retreive it from the database using a a system DSN through ODBC. In this way we hope to present our users with more flexibility in designing their own reports. What we do want to ensure though is that these system DSNs are configured correctly when the user installs our program or when the program calls the Crystal Report.
Is there a smart way to do this using System variables for instance, instead of having to write a routine that checks for OS-version, whether UAC is enabled on the OS, whether the write restrictions on the Program Files folder have been lifted, etc and then adapts he System DSN to point to either the C:\Program Files\OurApp\Data folder, or the C:\Users\User\AppData\VirtualStore\Program Files\OurApp\Data folder?
Suggestions for an entirely different approach are welcome too!
New applications should have an application manifest that specifies requestedExecutionLevel. This declares your program "Vista aware" and bypasses attempts at virtualization.
During installation you should create a folder like [CommonAppData]\Company\App\Full and set security on this folder to allow Full Access by Everyone (or by Users). Put your database into this folder.
For an MDB you can drop the database right here. For a client/server database put a UDL file here. Also see Use Universal Data Link (.udl) Files.
ODBC and DSNs are pretty obsolete technologies.
Using the suggested approaches should work for almost anything but the oldest Win95 computer.
Is this an Access database? You haven't specified.
For an Access database, you don't need to point your DSN to a specific database when you install it. You can modify the connection string to point to different databases at runtime (details). For instance
Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;
Can you simply read the installation path at runtime (in VB6 it is App.Path) and then send a different connection string to Crystal Reports?
It seems that Virtual Store takes care of everything, so you can point the DSN blatantly at C:\Program Files\MyApp\Data\mydb.mdb even while the database has been relocated to the Virtual Store.
Current Version
You might want to detect the current-version of Windows the system is running.
This will in turn help You in determining the correct PATH.
How to find windows version, build and revision numbers??
Read the the Registry keys ā
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EditionID
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProductId
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\BuildLabEx
The CurrentBuildNumber is your Windows Build Number. Then CurrentVersion value is your windows version i.e. the version of your windows 7, windows vista, windows xp, etc. EditionID and ProductId to know the windows-edition and product-id.
The key BuildLabEx contains build number and revision number.
For example, in the value 6001.17387.x86fre.vistasp1_gdr.070927-1921:
the first four digits stand for build number i.e. 6001 and
the next five digits stand for windows revision number i.e. 17387.
x86 tells you that you are running a 32-bit operating system.
You might also be interested in this:
How to detect true Windows version?
GoodLUCK!!